[CMake] parsing config.h files and setting cmake variables accordingly
Clemens Arth
clemens.arth at gmx.at
Fri Feb 13 06:46:03 EST 2009
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
More information about the CMake
mailing list