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

[EJ Nikelski]

Hi all,

   Thanks for your feedback, Andrew.  I *did* notice the
CMakeLists.txt file in the MINC distro and wondered what you were up
to  ;)      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.  Let me address some of your points
...

> * There are no inbuilt "make dist" "make distcheck" type things with
> the same ease of use of autoconf.

  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. I test converted the
"arguments" package (since it was fairly simple-ish, and it needed
some TLC) and I did:

cmake .. (within the build dir for out-of-source builds)
make
make test
make install
make package (creates a binary package)
make package_source (creates a source package)
**done**

  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.


>
> * 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.  Happily, the online
documentation has gotten much better, and is pretty much as good as
the book.


>
> * 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.

>
> * There are far far less macros out there for use in other things
> (like find me GLUT, find me GL, etc). You will note that I have a

  Yeah, but given that these modules are written with a consistent
syntax (CMake), we are seeing lots of macros being written ... I
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.


>
> * CMake seems to me to be written for the purpose of building
> executables and libraries (fair enough) whereas autoconf/automake also
> caters for the package builders and testers amongst us.

  Perhaps, but things are changing rapidly.  CPack can do a reasonable
job packaging, and CTest makes writing unit tests a breeze.  The
"arguments" package had one test (which was broken), which I replaced
with 7 (which work).  Super simple to do.

>
> 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).  The
purpose, with reference back to the original problem that Alex
reported, is to make writing and maintaining these build scripts
easier, so that average developers would feel comfortable
trouble-shooting build problems, which in turn would make them more
likely to offer a fix.  So the idea is actually to make it possible to
better distribute responsibility for build scripts.

Now -- off to sleep.

-Jim