On 2007-06-23 18:54-0400 Dave Wolfe wrote:
I have a project with some (home-brewed) IDL files that I need to run
a python script on to convert to CPP. Some of these IDL files
include other IDL files, which may, in turn, include *other* IDL
files...
It appears from what you have said, that ...
you need to deal with the
dependencies dynamically at build time rather than cmake time.
Yes, that seems to be the case.
If you were willing to accept static idl dependencies then you could
use EXECUTE_PROCESS to run your python script to generate the cpp file
and determine a static list of idl dependencies at cmake time, and use
ADD_CUSTOM_COMMAND to regenerate the cpp file (if necessary) at build
time (i.e., make time) if any of the static list of dependencies has
been changed/edited (aside from changes to include commands). Of
course, you could remove the cache file and rerun cmake to update the
list of static dependencies that are paid attention to in the
Makefile, but that takes human understanding of when the include
statements have changed so the procedure is subject to human error but
may be a compromise that reasonably satisfies your needs.
Hmm. Is there a way to 'fake out' CMake so it re-runs itself the next
time a target is built? Maybe make a build rule that touches the
top-level CMakeLists.txt file, or some other file? That wouldn't be a
perfect solution, but it would be good enough, I think...
I don't know.
Here are two other possibilities to give you some food for thought.
(1) I have never done this myself, but I have heard on this list that for
really intricate stuff it is nice to use a cmake -P script (presumably
at build time as part of a custom command). Anyhow, you should look at
that possibility to see if it might answer your needs.
(2) You could just forget about all the dependency stuff and simply use a
custom target (as opposed to a custom command) to _always_ regenerate
the CPP file at build time regardless of whether there has been a change
or not in the idl files. That is certainly a safe procedure, but you
will have to be the judge of whether it is acceptably efficient or not.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
