[CMake] configuration input to cmake

[Guilherme Balena Versiani]

Hello Jun Sun,

I hope now I understood your question.

First, let compare auto-tools to cmake: the three main steps involved in 
building the system are about the same (though the cmake seems to use a 
better cache system than 'configure' and it generates a something 
optimized set of GNU Makefiles compared to auto-tools):

    1) ./configure = cmake <path-to-src> = ccmake <path-to-src>
    2) make (Makefile generated by ./configure) = make (GNU Makefile 
generated by cmake)
    3) make install = make install

So, I think your question is similar to the following auto-tools question:

  - Should I pass a 'make' metavariable or should I use a 'configure' 
command line option for obtaining 'xxx'?

I see that 'pass config options to cmake' (option #1) is better for 
choosing things like modules (this strategy is used by many projects 
like PHP, Apache, Lighttpd, freeradius, etc).

Thinking that way, I propose to you something like the following code:

    # suppose 'A' module is built by default
    SET(USE_A TRUE
        CACHE BOOL
            "This flag enables the 'A' module of the project.")

    # suppose 'B' module is not built by default
    SET(USE_B FALSE
        CACHE BOOL
            "This flag enables the 'B' module of the project.")

    IF(USE_A)
        ADD_DIRECTORY(module_A)
    ENDIF(USE_A)
    IF(USE_B)
        ADD_DIRECTORY(module_B)
    ENDIF(USE_B)

    # ... some other code ...

    IF(USE_A)
        INCLUDE_DIRECTORIES(module_A/include)
        # the final target needs to link against module_A
        TARGET_LINK_LIBRARIES(myproject module_A)
    ENDIF(USE_A)
    IF(USE_B)
        INCLUDE_DIRECTORIES(module_B/include)
        # the final target needs to link against module_B
        TARGET_LINK_LIBRARIES(myproject module_B)
    ENDIF(USE_B)

This way, you get on ccmake (ncurses-based interface for UNIXes) and 
CMakeSetup (for Windows), something like this:

    USE_A   TRUE     <-- This flag enables the 'A' module of the project.
    USE_B   FALSE   <-- This flag enables the 'B' module of the project.

If you would not like to use the ccmake nor CMakeSetup, and you need to 
compile module_B and not module_A, for example, you would use the 
following command-line to cmake:

    # cmake -D USE_A:BOOL=FALSE -D USE_B:BOOL=TRUE

If you need to change some types of configuration variables, like the 
installation prefix, for example (e.g. /usr/local), you would rather 
pass this option to make itself than changing cmake cache (though the 
both ways get to the same target). You would change the DESTDIR variable 
for this purpose, like auto-tools (make DESTDIR="/home/me/mydist" install).

----

By using this cmake strategy you bring the same configuration options to 
other systems like Windows and Mac OS X, by using cmake native 
capabilities. If you use 'make' variables, you narrow your solution to 
'Makefile' systems (then you need to check if all nmake/gmake/etc uses 
identical metavariable passing), so you need to imitate the same 
behavior on other systems by hand.

So, if your application should build on other systems different than 
UNIXes, I think the option #1 is far the best one.

Regards,

Guilherme Balena Versiani.


Jun Sun escreveu:
> Thanks for the pointer. But I was referring to the configuration
> for the cmake itself. For example, one build may include module A
> and another build may not include module B instead.
>
> Now thing about it, what is the recommanded way of achieving this goal?
>
> I can thinking of two ways:
>
> 1. Pass config options to cmake itself so that it generates two
>    different make systems that does two things
>
> 2. Somehow generate just one make system but the make system itself takes
>    an input argument that dictates which way to do the build.
>
> Which one is better in cmake world? I was thinking about 1).
>
> Thanks.
>
> Jun
>
> On Fri, May 11, 2007 at 02:22:46PM -0300, Guilherme Balena Versiani wrote:
>   
>> AFAIK using cmake involves basically two steps:
>>
>> 1) something like configure & generate build files (GNU Makefile, MSVC, 
>> KDevelop3, XCode, etc). For a tipical 'out-of-source' building:
>>
>>    # mkdir <build_dir>
>>    # cmake ../<source_dir>
>>
>> 2) build software:
>>
>>    # make
>>
>> Optionally, you can have a 'make install' (see INSTALL command), a 'make 
>> package' (which means you are using CPack) and 'make test' (see CTest).
>>
>> Regards,
>>
>> Guilherme Balena Versiani.
>>
>>
>> Jun Sun escreveu:
>>     
>>> My build process involves a configuration stage. It roughly looks like
>>> this:
>>>
>>> * Generate cmakefile.inc and config.h from .config file
>>> * Use cmake to generate solution files or makefiles
>>> * Build with native toolchain
>>>
>>> It is not clear to me whether I should use an external script to do 
>>> step 1 or I can even do the first step with cmake itself.
>>>
>>> I am very new to cmake. Sorry if this is a dumb question. :)
>>>
>>> Cheers.
>>>
>>> Jun
>>> _______________________________________________
>>> CMake mailing list
>>> CMake at cmake.org
>>> http://www.cmake.org/mailman/listinfo/cmake
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guibv.vcf
Type: text/x-vcard
Size: 323 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20070514/6afa5333/guibv-0001.vcf