[MINC-users] Register's configure test for GLUT

[Andrew Janke]

2008/8/20 EJ Nikelski <nikelski at bic.mni.mcgill.ca>:
>   Thanks for your feedback, Andrew.  I *did* notice the
> CMakeLists.txt file in the MINC distro and wondered what you were up
> to  ;)

Heh.  There is (generally) method in my madness.

>  I do believe, however, that since CMake development is
> moving rather quickly (there appears to be an astonishing growth in
> *.cmake modules), some of your earlier experiences with CMake may no
> longer reflect the current CMake.

No doubt.

>  Correct, I do believe that a "make distcheck" functionality does not
> yet exist, however, the current CPack mechanism does seem to do a
> fairly reasonable job creating packages.

That it does. Still to me it is clumsy to have a separate doo-hicky to
do this to CMake (but this is not a technical point!).

>  CPack can create all sorts of packages: tar.gz, .deb, dmg (not
> tested yet) ... although there are a few gotchas (bugs) to look out
> for.

Aye, that was my experience a while back too. easy to use for small
things but it can get hairy for larger projects.

>> * There is far less out there in terms of documentation. I refuse to
>> buy a $80? manual for something that is "free". Especially as the
>> manual will change.
>
>   Yup, the price of the manual is a bit steep, although many open
> source projects use printed documentation as a "value add" in order to
> generate some income for the developers.

I certainly don't disagree with this model, what I do disagree with
though is me making choice to shift to CMake (and thus buying the
manual) which will in turn force a bunch of others out there who might
want to extend MINC or fiddle with the build process to buy a copy
too. MINC is supposed to be free! :)

> Happily, the online documentation has gotten much better, and is pretty much as good as the book.

Good good, where is this docco?

>> * CMake is strongly slanted towards VTK/ITK (no surprise there).
>
>  Ummmm ... not sure what "slanted" implies.  Yes, they're big users,
> but so is the KDE4 project.  I can't see any down-side here.

The inbuilt macros are (not suprisingly) written for use in VTK/ITK programs.

>  Yeah, but given that these modules are written with a consistent
> syntax (CMake), we are seeing lots of macros being written ...

Is there a repository of these somewhere? I couldn't find them ala the
automake macros archive.

> suspect, many by people who would not have dared try the same with m4.
>  BTW, "FindOpenGL" (includes find GLU as well), and "FindGLUT" are
> standard modules in CMake 2.6.  All we need is FindSoQT and FindCoin,
> and I would be able to finally build brain-view on my OS X machine
> using -frameworks.  I would like that.

Be my guest... :)  I wrote FindMINC and friends...

>> Note that I am not making a case for/against CMake but now I reckon I
>> will continue with autoconf if only because of the enormous amount of
>> work required right now to shift everything.
>
>  I agree.  But does it really need to be an "all or nothing"
> approach? Perhaps we could try implementing new projects using CMake,
> in addition to allowing inspired (or bored?) users to fix/enhance
> existing packages (as I did with the "arguments" package).

I will never hinder the inspired who choose to write things for me. :)
 I am more than happy to add your CMakeLists.txt file to the arguments
package (and any others that you choose to do).

There is some automake -> CMake converter thing that I found a while
back but it doesn't capture everything.


a