Boost logo

Boost Interest :

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-27 08:19:35

Beman Dawes wrote:
> On Thu, Jun 26, 2008 at 10:31 PM, troy d. straszheim
> <troy_at_[hidden] <mailto:troy_at_[hidden]>> wrote:
> David Abrahams wrote:
> troy d straszheim wrote:
> Things look good. So... Dave is it possible you were doing
> configuration of cmake in a build directory that had failed
> configuration once?
> Gosh, I don't know. Maybe. Probably. Heck, shouldn't that
> work, after
> all!? How will our users survive if one failure torpedoes all
> further
> attempts?
> It is just a standard cmake gotcha: configuration/generation
> fails, the cache isn't deleted, and whatever it was that caused the
> failure is preserved in the cache to fail on the next attempt. You
> can reduce this effect by being careful what you cache, but in this
> case, well, we're still just hackin' on this thing....
> I thought cmake was supposed to be robust. This is very discouraging; it
> implies cmake developers are only targeting folks who are cmake experts.
> Is it possible to disable this misfeature?

I think Troy is saying that we get to control what gets cached, and as
our system gets more refined, we'll figure out what to cache and what
not to.

IIUC this is really the same model as autoconf and that has the same
issue, but it's not a big problem for people... it's just that it's
well-known how to blow away an autoconf cache.

Dave Abrahams
BoostPro Computing

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at