[CMake] parsing config.h files and setting cmake variables accordingly

Michael Jackson mike.jackson at bluequartz.net
Tue Feb 17 08:43:09 EST 2009 

I would say that something isn't quite setup correctly with your cmake  
project because lots of us use this technique and it works as  
advertised. All I can think of is there is a loss of a dependency  
somewhere.

---
Mike Jackson                 www.bluequartz.net



On Feb 17, 2009, at 1:35 AM, Clemens Arth wrote:

> Yes, that was exactly what I did and it works on Linux, but it does  
> not help in VS, unfortunately... VS sets up all the includes and  
> linking options right, but then it prompts me to reload the project,  
> and that's it....
> only a complete "rebuild" lets the  project recompile the sources.
>
> Clemens
>
> Michael Jackson wrote:
>> 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