[CMake] Clear cache on upgrade?

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Apr 23 18:48:37 EDT 2012


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
__________________________


More information about the CMake mailing list