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

[Clemens Arth]

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
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>