[CMake] Clear cache on upgrade?

2012-04-23 Thread Robert Dailey
I am wondering what a good rule of thumb is when upgrading CMake. Should I
delete my cache after each upgrade? I'm on Windows.
--

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

Re: [CMake] Clear cache on upgrade?

2012-04-23 Thread John Drescher
On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
 I am wondering what a good rule of thumb is when upgrading CMake. Should I
 delete my cache after each upgrade? I'm on Windows.
 --

I never ever do that on windows. And I have done 100s of builds with
CMake and many upgrades since CMake 2.4.

John
--

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


Re: [CMake] Clear cache on upgrade?

2012-04-23 Thread David Cole
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.


HTH,
David


On Mon, Apr 23, 2012 at 2:06 PM, John Drescher dresche...@gmail.com wrote:

 On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey rcdailey.li...@gmail.com
 wrote:
  I am wondering what a good rule of thumb is when upgrading CMake. Should
 I
  delete my cache after each upgrade? I'm on Windows.
  --

 I never ever do that on windows. And I have done 100s of builds with
 CMake and many upgrades since CMake 2.4.

 John
 --

 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

--

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

Re: [CMake] Clear cache on upgrade?

2012-04-23 Thread John Drescher
 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.


Fully agreed.. It has been quite rare that a CMake upgrade has caused
a problem or a need to re configure.

John
--

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


Re: [CMake] Clear cache on upgrade?

2012-04-23 Thread Alan W. Irwin

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