Eduard Bloch wrote:
#include <hallo.h>
* Brandon J. Van Every [Fri, Aug 25 2006, 01:19:13PM]:
Eduard Bloch wrote:
Okay. I made a similar thing... removed the absolute path completely so
it is now generated in CMAKE_BINARY_DIR and I added ${CMAKE_BINARY_DIR}
to the INCLUDE_DIRECTORIES of each CMakeLists.txt.
This works sufficiently, all new files can be removed by nuking the
build directory. However, running "make clean" there still does not
remove those file by itself, it only removes the executable/library
targets.
Philosophically, you're talking about a difference between configuring
things and making things. Things that are configured are generally not
supposed to be cleaned, either in CMake or in GNU Autotools. A
./configure script will typically generate config.h, and this is not
nuked by "make clean" either.
In theory, yes. However, the need to configure something and put the
result down in a include file is IMO a common case among portable
programs. I know that this action is an additional level of operation
placed beetween cmake configuration and the final making. So effectively
there should be a way to _simply_ define a temporary product (the
config.h file) as target which other targets do pre-depend on (so the
first must be proccessed before making others and never be executed
simultaneosly). And I wish there would be "virtual prerequisites", eg.
the operation would be triggered if the hostname or kernel version
changes. And there should be a "distclean" rule to remove such temporary
products like configuration headers. Alternatively, the config files may
be kept but then the detection of their pre-requisites must be
waterproof.
Good fodder for a feature request. Use the bug tracker to make it.
http://www.cmake.org/Bug/ I agree that I'd like to not have to do a
song and dance to get a configuration file to be cleaned. At present,
I simply re-run CMakeSetup, and that's adequate to my needs. I always
do out-of-directory builds, so if I want everything to be "distclean,"
I just wipe my build tree and start from scratch. Again this is
adequate to my needs.
If you want to perform substitutions at make time, you will need to
write a *.cmake script containing CONFIGURE_FILE, and wrap that script
up in an ADD_CUSTOM_COMMAND. You'll have to pass your pathnames with -D
flags on the *.cmake script command line. There is a bit of a learning
curve about CMake scripting here. It is all kinda tedious, enough so
that I feel less like typing up an example, and more like asking how
important this is to you? Would the "it's a configuration" philosophy
be plenty appropriate for your needs?
I am not sure whether it is okay for may needs. Because I am not sure
that I understand the design goals of cmake to 100 percent. I would like
to see in clear sentenses what exactly is triggering what when cmake
does things.
What you describe may be something like I mentioned above scripted in
the cmake language, but I don't know how and when the code will be
executed and how I can influence this to be executed not too often but
also always then when it is needed.
An ADD_CUSTOM_COMMAND is just a dependency rule. It has the same
functionality as a rule in a makefile, gets invoked at the same time as
such rules, and indeed is just syntax for specifying such rules in a
cross-platform way.
CMake scripting is just what you're choosing to do. You could choose
to use native platform tools, like sed or awk or perl or whatever.
CMake doesn't care. That's why it's a *CUSTOM* command.
Cheers,
Brandon Van Every
|
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
