[Insight-users] Re: [Fwd: Advice]: About the CMake initialization file

[Bill Hoffman]

Here is a question from Neil Killeen <nkilleen@atnf.csiro.au>,
and my answer.

-Bill





>I am now trying to make my final setup for our medical imaging system;
>I continually find something rather frustrating and suspect
>there must be a better way to do it.
>
>So if I can describe what I am doing (its very simple)
>
>I have a system (called mitk !) with structure
>
>mitk
>   /Data
>   /Source
>   /Output
>         /sun4sol
>         /linux
>
>
>under cvs control.
>
>
>I plan the following usage:
>
>. a daily system gets checked out and built for
>   1) testing purposes
>   2) somewhere to put the web pages for the system
>
>. developers will check out the system, update as needed
>  and commit code as per usual
>
>
>Now, you can see I have put
>
>   /Output
>         /sun4sol
>         /linux
>
>
>under cvs.  All that lives in these directories
>are CMakeCache.txt files.
>
>
>However, as we know, whenever you move from one output directory
>to another, a CMakeCache.txt file has to be hand-edited to make it work
>(I find this VERY annoying - also that if the source moves you
>have to hand edit)
>
>So as it stands at the moment, a developer would
>
>. initially checkout the system
>. edit (say) Output/sun4sol/CMakeCache.txt
>. run cmake
>. build their system
>
>
>Now, to build the daily system in a script, I would have a cron
>job that runs (at midnight) something like
>
>
>#!/bin/csh
>cd /nfs/mid/software/mitk/Daily/mitk      # Position
>cvs update                                # Update
>cd Output/sun4sol
>cmake ../../Source                        # Regenerate makefiles
>make                                      # Build
>
>
>the problem is that the CMakeCache.txt files that I have checked
>in can ONLY work for one output directory. So I very carefully
>make them correct for my Daily output tree.
>
>But this is a very ugly situation; if I want other flavours
>of the system I have to edit the stupid things which I
>can't do sensibly in a build script !
>
>How do you handle this  (as you commented you run squillions
>of versions of the system).
>
>Do you put these files under cvs control or do you leave
>the output tree entirely static - this means that a new
>developer has no template CMakeCache.txt file to work from.
>
>I really do not like this system of positioning yourself in the output
>tree - as I think I may have commented before :-) !
>
>
>thanks
>Neil
>
>
>
>p.s. I built the new ITK release with no errors or problems.
>Also I see now the applications are in their own tree
>which is good.  So nice job guys !

Hi Neil,

I would strongly recommend against putting CMakeCache.txt files under cvs.
It would be like putting config.cache files from autoconf under cvs.   
This file is generated by cmake as it determines where things are on
the system.   Once it is moved to a new system, these values are likely
to be incorrect, and you will get strange errors.

The problem comes because cmake can not always find everything you need
automatically, and there are users specified options.  
The trick is to figure out which things you always have
to specify for a particular system.    In most cases there are only a small
number of things that are required to be specified by hand.   The rest of
the options can be set automatically by cmake.   

I guess your system uses VTK, ITK and FLTK.    If you have standard places on your
systems where these things are located, that cmake can not find, you can specify
them in two ways.

1. The command line to cmake can take a -D option that is used
   to specify cache entries.    The format looks like this:

   cmake  -DVALUE=TYPE:SETTING -DVALUE2=TYPE:SETTING

2. You can create an cmake input file that is read by cmake at start up.
   This file is in the cmake syntax, but be careful to set variables as
   cache values like this:

   SET(VTK_USE_HYBRID ON CACHE BOOL "doc string")

   Once you create the init file, you can tell cmake to use it with
   the command line option:
   -Cinitfile.cmake

   cmake -Cinitfile.cmake


Of course with either approach this will only work if the values you 
are specifying are valid for the system you are running on.

We normally do not cvs checkin CMakeCache files or init files for
our dashboard builds.    We usually, write system specific scripts for
each system that runs a dashboard, and use the -D command line option to
populate the cache with the values for that system.    If all of your linux
systems have VTK, FLTK installed in the same place, and that place is not
the normal place (i.e. /usr/local/ ) you could check in a file that users
could use with a -C option to cmake to get things started.

CMake is not that much different than configure.    With a complicated system built
with configure, you often have to specify many options on the command line to configure.
--with-foo=/path/to/foo --with-bar=/path/to/bar.   I guess with a configure based
system you would check in a script with the correct options to configure to achieve 
the same goal.   The equivalent in cmake, would be a script with -D options.
CMakeCache.txt file should not be transferred from system to system.



>I really do not like this system of positioning yourself in the output
>tree - as I think I may have commented before :-) !

I am not sure I understand this comment.    You can do an in-source build or
an out of source build with cmake.    What other types of builds are there?
This is very much the standard for unix software based on configure.   


-Bill