On 2013-09-16 17:24-0000 Williams, Norman K wrote:
OK, yeah, I know about disabling updates. I don't remember who or when I
got the advice NOT to disable updates.
And all of the projects in our Super-Duper-build do get set to specific
SVN/GIT/CVS tags. This is the only way
to get predictable behavior.
And my reasoning was 'if you always request a specific tag, you never need
to have an update command.' But then I was told to leave that be.
The only rationale for always updating is that if you change the tag to
download, it will re-download the source, and rebuild with the new source.
If you disable update then you'll have to delete the files down in
<PRJ>-prefix/src/<PRJ>-stamp to retrigger a download.
Or do what I generally do and delete the source, build, AND prefix
directories.
All of this starts out as 'expert-level CMAKE hacking' and gets
progressively more abstruse as I go along. I keep trying to think of how
to simplify it for people who want to build and use applications using the
SuperBuild. Not sure who they are, or if I really should try and bend over
backwards to make things easy for them.
I suggest you try 2.8.12. The reason I say that is for CMake versions
before 2.8.12, the cmake -E touch command (used a lot within the
ExternalProject module) has only one-second time resolution, i.e., the
time for the file that is touched is rounded down to the nearest
second. Anyhow, I worked around the problem by replacing cmake -E
touch everywhere by the system touch command within a local version of
the ExternalProject module, and a lot of annoying dependency issues
disappeared as a result. (I could use that workaround because Linux
and MSYS are the only platforms where I currently use ExternalProject,
and a system touch command is available for both those cases.)
Apparently this time resolution issue for the cmake -E touch command
has now been fixed for CMake-2.8.12 (for platforms that support
setting file update times to better than one second). I don't know
whether your particular dependency issue will be fixed by that, but it
should certainly be worth trying CMake-2.8.12 as a first step whenever
annoying dependency issues are discovered for the ExternalProject
module for prior CMake versions.
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://www.cmake.org/mailman/listinfo/cmake
