Subject: Re: [Boost-build] Better caching of configure checks
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-10-15 17:12:35
On 10/15/2012 01:41 PM, Jürgen Hunold wrote:
> Hi Steven,
> On Saturday, 13. October 2012 18:12:26 Steven Watanabe wrote:
>> The attached patch implements a cache that
>> stores the results of all configure checks.
>> This reduces the no-op build time
>> for msvc-11.0 in BOOST_ROOT with no extra
>> options from 8 seconds to 3 seconds for me.
> Nice work. This really speeds things up.
>> The --reconfigure option causes the
>> cache to be regenerated from scratch.
> This needs to be documented very well. I wonder if "--configure" would be more
> consistent. But that might be bikeshedding from my side ;-)
I don't know. To me --configure would imply
that configuration checks are only run when
you pass the flag, when in reality they also
run whenever they aren't found in the cache.
> Is there an option to force reconfiguration or disabling the cache from site-
> config.jam or user-config.jam? This might come handy when setting up 3rdparty
> libraries. This requires some experimenting and dirty caches can get in the
> way *fast*. This is what is annoying with CMake...
There isn't, but I can easily add a config-cache.disable rule.
I could also allow something like
using ... ;
which would allow disabling the cache for
specific initializations that you think
are liable to change.
>> I think that passing -a should also clear
>> the cache, but I put that off, since
>> the engine doesn't expose most of its
>> flags to Jam code. (I'd rather not
>> duplicate the option parsing logic
> Yes, this can be refactored later.
The relationship between --reconfigure and -a
goes both ways. --reconfigure should also force
all configure checks to rebuild.
>> I've tested this with msvc-9.0express,
>> msvc-10.0express, and msvc-11.0 on
>> Windows 7 and with gcc-4.5.1, gcc-4.7.2,
>> and clang on linux.
>> Any thoughts on this before I commit it?
> I'd like this to be mentioned *at least* in "b2 --help" output somewhere at
> the top. And of course in the getting started guide(s).
I've already adjusted the regular configure output
to indicate which checks are cached. e.g.
- long double support : yes (cached)
Hopefully, this is enough to prevent surprises.
I'll definitely document the details of the behavior
in the Boost.Build docs as well.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk