[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