[MINC-development] compiling Display from github

[Jason Lerch]

Thanks for the cmake pointers. Two questions for the dumb ones amongst us (i.e. me):

* what's the equivalent of --prefix and our --with-build-path? 
* does everything (MINC, BICPL, etc.) have to be built with cmake or can one mix and match make and autotools?

I got the development branch, and tried running cmake, which barfs with the following error:

CMake Error at CMakeLists.txt:118 (find_package):
  By not providing "FindLIBMINC.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "LIBMINC", but
  CMake did not find one.

  Could not find a package configuration file provided by "LIBMINC" with any
  of the following names:

    LIBMINCConfig.cmake
    libminc-config.cmake

  Add the installation prefix of "LIBMINC" to CMAKE_PREFIX_PATH or set
  "LIBMINC_DIR" to a directory containing one of the above files.  If
  "LIBMINC" provides a separate development package or SDK, be sure it has
  been installed.


-- Configuring incomplete, errors occurred!

MINC and friends are compiled into /usr/local/minc2 (with autotools) with nary a .cmake file to be found under that tree. I'm sure I'm just forgetting something simple and obvious …

Jason

On 2012-11-05, at 11:03 AM, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:

> Exactly
> 
> On Nov 5, 2012 11:01 AM, "Jordi Gutiérrez Hermoso" <jordigh at octave.org> wrote:
> On 5 November 2012 10:39, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> > On Mon, Nov 5, 2012 at 10:28 AM, Jordi Gutiérrez Hermoso
> > <jordigh at octave.org> wrote:
> >>
> >> On 5 November 2012 10:03, Jason Lerch <jason at phenogenomics.ca> wrote:
> >> > No, I was using the master branch. I'll give the devel branch a try
> >> > later - which I guess will include trying to understand the god
> >> > forsaken cmake build system (I know that autoconf sucks and the
> >> > thought of writing anything in m4 is horrid, but at least I got used
> >> > to it!).
> >>
> >> Cmake sucks too, since it's a lot more difficult to write custom tests
> >> for it that aren't already built-in. It's less flexible than
> >> autotools, but using it as a user should be no more difficult than
> >> autotools. Instead of doing
> >>
> >>     cd build-directory ## optional
> >>     /path/to/configure
> >>     make
> >>     make install
> >>
> >> do
> >>
> >>     cd build-directory ## optional
> >>     cmake /path/to/CMakeLists.txt
> >>     make
> >>     make install
> >>
> >> As we say in IRC, "The 'suck' is a unit vector. A given foo doesn't
> >> suck LESS, it just sucks in a direction a given hacker finds less
> >> disagreeable."
> 
> > Are you ready to take over as official minc maintainer?
> 
> No, I didn't mean to say that CMake is a bad choice. Building is a
> chore. All choices are equally annoying. For MINC, CMake may have a
> 'suck' vector in a better direction than autotools. I'm used to both
> and I dislike both for different reasons, but I've disliked every
> build system I've ever seen (ant, Scons, bjam...)
> 
> > If you are not, then in this particular situation your 'suck' vector is
> > purely imaginary.
> 
> So it points straight up in the complex plane? :-)
> 
> - Jordi G. H.
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20121105/bb6b5a15/attachment.htm>