[CMake] ExternalProject feature regenerating the configure script

Alan W. Irwin irwin at beluga.phys.uvic.ca
Tue Jul 30 02:24:53 EDT 2013


On 2013-07-29 18:21-0700 Ashok Nalkund wrote:

> After digging around more, I found that the copy_directory command to cmake 
> may be causing some issues. The package sources have the correct timestamps 
> for the Makefile.am and Makefile.in. But as part of the ExternalPackage_Add, 
> the download step does a 'cmake -E copy_directory' which then results in the 
> Makefile.in being newer than Makefile.am:

That's a real bug in the ExternalPackage module since I have verified
that 'cmake -E copy_directory' does not preserve timestamps in the
slightest, and I believe the implementer of that module assumed either
(1) that 'cmake -E copy_directory' did preserve time stamps or (2)
didn't realize the importance of such preservation (at least for the
autotools case).

The only use of cmake -E copy_directory within the ExternalProject
module is contained within a

if(IS_DIRECTORY "${url}")

block, with a message constructed from

set(comment "Performing download step (DIR copy) for '${name}'")

For now, one possibility to preserve the timestamps of the files is to
replace that cmake -E copy_directory command 
with a combination of the

cmake -E tar cf ....
cmake -E tar xf ....

commands, but specifying the directory appropriately for those two
commands to do the equivalent of copying ${abs_dir} to ${source_dir}
may be complicated within the constraints of the ExternalPackage
module CMake logic.  For example, I don't think a naive approach would
work since all commands must be executed using the same working
directory.  So I suspect you will be forced to use a CMake script
(executed with cmake -P) to use the tarball create and tarball unpack
approach to preserve timestamps in the copied directory.

Anyhow, when you get that modification to work, then I would create a bug report
containing your patch for the ExternalPackage module so others can
benefit from your work.

Of course, an alternative fix would be a feature request for cmake -E
copy_directory to provide an option to preserve the timestamps, and
once that is request is implemented create another bug report with a
patch for the ExternalProject module to use that option for cmake -E
copy_directory.  But I suspect that is a long-term solution, and for
now a patch for the ExternalProject module similar to the suggestion I
have made above should be quicker/simpler to get into CMake.

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
__________________________


More information about the CMake mailing list