On 2012-04-23 14:13-0400 David Cole wrote:
A good rule of thumb is to try just upgrading CMake and running it on existing
build trees. It's obviously quicker than a re-configure
from scratch.
But then, before complaining about something not working, try it in a fresh
build tree first, then if it's still wrong, complain. :-)
It's rare, although it does happen sometimes, that we make a change in CMake
itself that invalidates something that's in an existing
cache.
Obviously (or maybe not depending on who you are), some sort of automated
testing, like nightly dashboards, should be doing full
re-configures on a frequent basis anyhow.
Just to give a slightly different view, I do reconfigure a lot more
than implied above. One reason I do it is I am often changing/updating
the CMake-based build system of whatever project I am working on, and
I don't think there are any guarantees that CMake will work in that
case without a complete reconfigure. Furthermore, even if I am not
fiddling with the CMake-based build system, I do often try new
versions of software my software package depends on that is installed
in a non-standard location. For that case I believe CMake just
continues to rely on the cached version of what it found before unless
you start updating the cached variables yourself, and I just prefer to
start fresh in that case (typically with PATH, PKG_CONFIG_PATH,
CMAKE_LIBRARY_PATH, and CMAKE_INCLUDE_PATH environment variables set
appropriately so the new version of the required software is found in
its non-standard location).
So even though it is the usual case that cmake reconfiguration is not
required, I think there are some obvious cases like above where it is
needed as well as not-so-obvious ones as well. So I definitely
endorse Dave's advice above to try a fresh build whenever some aspect
of the CMake-based build and/or test system doesn't appear to be
working correctly and certainly before any error is reported.
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
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
