[CMake] parsing config.h files and setting cmake variables accordingly
Michael Jackson
mike.jackson at bluequartz.net
Mon Feb 16 08:54:35 EST 2009
You would also want to add the configured file (config.h) to the list
of sources that get compiled.
configure_file(... config.h)
add_executable(MyApp main.c config.h)
That way the dependency is setup between the configured file and the
compilation of the executable.
Also I think it is generally better practice to have the input file
that is used in the configure_file command have the name "config.h.in"
rather than config.cmake. Having the .cmake file on the end may lead
to confusion when others look at your project.
Cheers
---
Mike Jackson www.bluequartz.net
On Feb 16, 2009, at 5:32 AM, Clemens Arth wrote:
> Hi again,
>
> now I have followed exactly that way and created a config.cmake
> file, which is translated into a config.h file. This approach works
> perfectly well on Linux and everything immediately responds to
> changes in the config.cmake file. However, if I create a Visual
> Studio project on Windows, the project itself gets updated according
> to changes in the config.cmake file, but the sources including
> config.h are not recompiled. Maybe I missed something, but even if
> the config.h file changes on a "build" command (and it really
> does!), the sources are all treated as up2date, so no rebuilding
> happens. Maybe there is a step missing, something like marking some
> files as dirty, but I don't really think so, or at least I can not
> imagine...
>
> Clemens
>
> Michael Jackson wrote:
>> That is the best way to do it. Have all the options in your CMake
>> file and let the user select which options they want to compile
>> with. Then "configure_file" to create your config.h file.
>>
>>
>> ---
>> Mike Jackson www.bluequartz.net
>>
>>
>>
>> On Feb 13, 2009, at 7:45 AM, Clemens Arth wrote:
>>
>>> Hello,
>>>
>>> the config files were written some years ago simply to collect all
>>> the possibilities how to compile the projects. Unfortunately this
>>> was long before cmake came into play, thus the problem just came
>>> up now because I wanted to set up a system for nightly builds.
>>>
>>> Well, I think the best solution might be to drop the old config.h
>>> file and to replace it by a file for setting the variables in the
>>> cmake environment, and finally to create a new config.h version
>>> with cmake online with a call to configure_file. I think, this is,
>>> in principal, the way you might have kept in mind when you
>>> suggested a look at configure_file, right?
>>>
>>> Regards
>>> Clemens
>>>
>>> Pau Garcia i Quiles wrote:
>>>> Hello,
>>>>
>>>> I see. So, where is that config.h created? In your CMake build-
>>>> system?
>>>> is it from an external library? If the former, maybe you could use
>>>> variables (cmake -DWITH_OPENGL:BOOL=1 ... ); if the latter, I don't
>>>> know (the only thing I can come with at this moment to survive
>>>> additional spaces, etc are regular expressions).
>>>>
>>>> On Fri, Feb 13, 2009 at 1:10 PM, Clemens Arth
>>>> <clemens.arth at gmx.at> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> thanks for the hint, but my problem is exactly the opposite of
>>>>> the one
>>>>> configure_file is solving. I'm already using configure_file in
>>>>> multiple
>>>>> places, but here I don't want to write config files, instead I
>>>>> want to parse
>>>>> their content back to cmake, and that's why I don't think
>>>>> configure_file.
>>>>>
>>>>> Regards
>>>>> Clemens
>>>>>
>>>>> Pau Garcia i Quiles wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Take a look at CONFIGURE_FILE
>>>>>>
>>>>>> On Fri, Feb 13, 2009 at 12:46 PM, Clemens Arth <clemens.arth at gmx.at
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've got a question concerning string processing in cmake.
>>>>>>> Our software
>>>>>>> framework consists of multiple libraries and has many
>>>>>>> different features
>>>>>>> to
>>>>>>> be enabled or disabled using #defines. For example, one option
>>>>>>> is to
>>>>>>> compile
>>>>>>> with OpenGL or with OpenGL ES support. Thus in a config.h
>>>>>>> file, one of
>>>>>>> two
>>>>>>> variables is valid to be #defined, USE_OPENGL or USE_OPENGLES.
>>>>>>> Depending
>>>>>>> on
>>>>>>> the variable defined cmake should link against a specific set of
>>>>>>> libraries.
>>>>>>>
>>>>>>> Currently determining which feature is set works the following
>>>>>>> way in my
>>>>>>> CMakeLists.txt:
>>>>>>>
>>>>>>> Code:
>>>>>>> # check for the configuration and set the corresponding GL/
>>>>>>> GLES libraries
>>>>>>> accordingly
>>>>>>> FILE(READ ${LIB_SOURCE_DIR}/include/config.h CURRENT_CONFIG)
>>>>>>> STRING(REGEX MATCH "\#define USE_OPENGLES" GLES_IS_SET $
>>>>>>> {CURRENT_CONFIG})
>>>>>>> STRING(REGEX MATCH "\#define USE_OPENGL" GL_IS_SET $
>>>>>>> {CURRENT_CONFIG})
>>>>>>> IF("#define USE_OPENGLES" STREQUAL "${GLES_IS_SET}")
>>>>>>> MESSAGE("GLES config!")
>>>>>>> ELSE("#define USE_OPENGLES" STREQUAL "${GLES_IS_SET}")
>>>>>>> IF("#define USE_OPENGL" STREQUAL "${GL_IS_SET}")
>>>>>>> MESSAGE("GL config!")
>>>>>>> ELSE("#define USE_OPENGL" STREQUAL "${GL_IS_SET}")
>>>>>>> MESSAGE("Error! USE_GL or USE_GLES must be defined!")
>>>>>>> ENDIF("#define USE_OPENGL" STREQUAL "${GL_IS_SET}")
>>>>>>> ENDIF("#define USE_OPENGLES" STREQUAL "${GLES_IS_SET}")
>>>>>>>
>>>>>>>
>>>>>>> Note that this is really a bad hack. First, if GLES_IS_SET is
>>>>>>> set
>>>>>>> ,GL_IS_SET
>>>>>>> is also set automatically. Second, if by accident the string
>>>>>>> does not
>>>>>>> exactly match the content (an additional <space>, or there is
>>>>>>> a second
>>>>>>> variable, for example called USE_OPENGL_EXTRAS), everything
>>>>>>> gets really
>>>>>>> weird or fails at all. Finally, a problem is that cmake does
>>>>>>> not actually
>>>>>>> notice if I changed the config.h file, so there should be an
>>>>>>> option to
>>>>>>> mark
>>>>>>> the configuration as dirty if the config.h file is altered -
>>>>>>> this is a
>>>>>>> problem which must not necessarily be solved, but maybe there
>>>>>>> is a simple
>>>>>>> solution to this.
>>>>>>>
>>>>>>> Can someone give me some tips how to improve my really ugly
>>>>>>> solution?
>>>>>>>
>>>>>>> Thanks and best regards
>>>>>>> Clemens
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
More information about the CMake
mailing list