[CMake] Updating files in the source tree.

[Alan W. Irwin]

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
__________________________