On 2014-06-28 13:52-0400 Rick McGuire wrote:
Sort of a long explanation/question here, so bear with me :-)
With our project, we have a number of source files that are generated from
.xml files. These generate a number of header files, message files, etc
using xslt. For a number of reasons, the generated files are also checked
into to SVN. Our old makefiles had the appropriate dependencies set up so
that so that when the source xml files were changed, these files would be
generated directly into the source tree and then checked in on the next svn
commit.
When we made the switch to CMake we ran into a lot of issues with trying to
output files into the source directorys, so we abandoned the automatic
generation and replace it with a small script we could run whenever we need
to update those files (doesn't happen very often and to date, I'm the only
developer who has ever updated this). This works for what I need.
However, the more I learn about CMake, the more I really like having CMake
to perform all of the build type steps. This separate build script sort of
bugs me, and I'm thinking that I could probably create some custom commands
that generate the files into the build directory and then copy them back
into the source tree.
The big question comes down to "should I?". Is doing this somehow a
violation of CMake rules/conventions? Are there any issues I need to
consider? And, the ultimate question is whether it is somehow possible to
set up dependencies where I could get back to the original build behavior?
Although I would be perfectly fine just having a target that allowed
updating those files on demand.
I don't think there is anything intrinsically wrong with the idea of
generating source files in the source tree, and I am surprised you had
any trouble implementing that when you converted your project to
CMake. Just use absolute (source tree) paths for all generated source files,
and
all should be well.
In the PLplot case, I haven't actually used that direct method because
the tools used for generating source code are sometimes problematic
and Linux-only, and in any case not all our users want to bother
installing those tools. So instead, the approach we often take is to
implement custom command/custom target pairs that create a target that
generates source code in the build tree and compares that result with
previously generated source code in the source tree. So an
experienced developer with all the generation tools installed can
check whether the source tree is internally consistent by running the
check_all target (which depends on the individual check targets). And
if one one or more inconsistencies are found, he can resolve those by
copying the freshly generated build-tree version(s) back to the source
tree. That copy step could be done automatically as well, but I
prefer to manually copy since that gives the developer a chance to
look at the generated result and compare it with the old generated
result in the source tree. (Some of our generation tools are a bit
problematic so it is good to diff with the old version just to make
sure all is well in our case, but your needs are probably different.)
I hope this discussion of some of the possibilities helps.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
