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.a...@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.a...@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
_______________________________________________
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
