[CMake] --enable-* with cmake

[Eric Noulard]

2007/8/10, gga <ggarra at advancedsl.com.ar>:
> Brandon Van Every wrote:
> > On 8/8/07, gga <ggarra at advancedsl.com.ar> wrote:
> >> I know I can pass -D symbols to cmake to modify its behavior and that
> >> windows also has its ugly CmakeSetup gui.
> >
> > "Ugly?"  Geez, what are you, a candidate for Windows Aero or something?
> >
>
> No, I am a candidate for something that works and ccmake/cmakesetup does
> not work well.  Don't confuse eye candy with functionality.  When I mean
> ugly, I mean there's basic functionality missing from ccmake/cmakesetup.

    I think this is clearer :))
    And the list you gave afterwards is interesting,
    I'll give my point of view on each item below.

> This, unfortunately, clearly rules cmake from being a good candidate to
> replace autotools, even if its core is much better.
>
> The problems with the current approach are:
>         - Variables for configuration are unknown to the user unless he
>           digs into all of the cmake modules used.
>           Compare this to running any autotools project:
>                ./configure
>           (you get full help for all the libs and options you can use).

            I think there is a confusion here.
           ./configure does not give you "full help" unless the writer
           of the configure scripts did it using --enable-xx or --with-xxx.
           I may well write ugly configure.ac (in fact I did it in the past)
           which won't help you AT ALL, even if the script will do its jobs
           perfectly.

           May be CMake user should be taught to use more OPTION
           in order to give more informations (using OPTION description)
           to the user.

>
>                ./cmake
>            (I get cmake's documentation, nothing about my project)
>               ../ccmake (on a clean project)
>            (Nothing)

           You are right this is annoying, I would very much like
           cmake / ccmake tell me something about my project
           if called in a build tree or a pristine source tree.

           They may list the project name and possibly the list of
           available OPTION with desc line.

           Something that mimics the behavior of ant -p
           (with the added verbose mode ant -v -p, which gives
            you even more informations)

           for compatibility reason I would avoid doing this
           when cmake is invoked without option but telling
           the user that a cmake -p will do the job.

>
>         - ccmake/cmakesetup list variables in the cache only.
>           If you are building out of source (as I do), the
>           CMakeCache.txt and the CMakeLists.txt are in
>           different directories, which again can be confusing to a user.

           I think a CMake user must be taught to understand out-of-source build
           there nothing CMake can (implicitly) do about this.
           However CMake supports in-source build too, such that "young"
           CMake user may continue to do in-source build.

           As a side note autotools does support out-of-source build
           but how many "occasional" ./configure user out there do use
           out of source build with autotools?
           Moreover I was pretty disappointed to discover that autoconf+automake
           do generates "some" files in my source tree even if I do
           out of source build (missing, install-sh etc...)
            This is a real annoyance because when you use the same
          source tree to build on different hosts using different version
          set of autoconf/automake sometimes you get message like this:

==============
    make distclean
 cd ../CERTI && /bin/sh /udd/deri/enoulard/workspace/CERTI/missing
--run automake-1.8 --gnu
/udd/deri/enoulard/workspace/CERTI/missing: line 52: automake-1.8:
command not found
WARNING: `automake-1.8' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.in'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
 cd . && /bin/sh ./config.status Makefile
===============

         even if the current machine a a perfectly running automake-1.10 !!


>         - As ccmake/cmakesetup rely on cached variables, a user running
>           the project for the first time will not get ANY variables
>           when he runs ccmake.  He HAS to run cmake first.

           I agree this is really puzzling, thoses tools should "at least"
           show you OPTION with associated desc lines.
           However this is not as easy as it seems because you
           may well have "optional" OPTION, i.e. which are OPTION
           defined if some other things discovered at CMake run time
           may enable/disable.

          In fact the only mean to know what option are available
          is to run CMake once...

>         - ccmake/cmakesetup lists pretty much ALL variables.
>           Scary as hell to a user not familiar with your project and
>           tedious to find the variable you need if you do know the
>           project.

>         - AFAIK, -D does not allow DISABLING options, like --disable-X
>           does.

             When using OPTION macro,
             -DOPTNAME:BOOL=TRUE enables and
             -DOPTNAME:BOOL=FALSE disables

             Note that effectively DISABLING something depends
             on the CMakeLists.txt writer just as when you use --disable-xxx
             using autotools it's up to the configure.ac writer to do something
             with the value set by ac_arg_enable macro.
             Again I may write a configure.ac which won't even take care
             of its --enable-xxxx option.


>           The FindXXX modules will take over and find the library
>           even if I told it to disable some library.

             Find modules do not "take over" the CMakeLists.txt writer
             is responsible for calling or NOT calling FIND_PACKAGE(whatever)
             depending on OPTION value selected by user.

             It is "just the same" behavior as AC_C_xxx macros for example.
             it is up to the configure.ac writer to call them when appropriate.
             For example if you define your --enable-X-support option
            you should "normally" conditionally call AC_PATH_X
            but I promise you that autotools won't help you in not calling
            AC_PATH_X when --disable-X-support is called.
            YOU should take care of that.


I think your remarks are illustrating the fact that CMake users do not
usually follow "common rules" for writing their CMakeLists.txt
because there is none, whereas you have many indications
in the autoconf manual.
(http://www.gnu.org/software/autoconf/manual/)
Since CMake does not enforce you the way to go you end-up
with an apparently less consistent behavior than the ones
you usually obtains with autotools.

I think consistency and most of the CMake deficiencies
(but the "available" OPTION list ) you have
identified are due to CMake usage and not CMake itself.


-- 
Erk