$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Configuration framework (Was: [Regex] Building Boost.Regexwith ICU)
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-09-22 04:03:02
> I think the important question here is what mode do we want.
>
> One mode is where you have a feature test as a .cpp file which tries to
> use
> "important" functions from a library, and then declare a Boost.Build
> metatarget that builds that .cpp and links to a library. In this case,
> if you modify the .cpp, the regular dependency checking will rebuild
> the test. Also, the test will be repeated if the system headers for the
> library change -- a particularly nifty example is including
> "whatever/version.hpp" and making some decisions based on version.
> Some changes to the way libraries are linked will allow the test to be
> rebuilt when a system library itself is modified.
>
> Another mode is where configure checks tries to compile or link something,
> and caches the result. One can remove the cache and run all checks again,
> but otherwise the system assumes nothing changes.
>
> I, personally, is not very happy with the second mode as implemented in
> cmake. However, it might be that the best mode depends on the nature of
> the
> test, and we need to support both. Comments?
I'm not happy with the second mode either - if something in the source
changes then the test should definitely be rebuilt - most users will
presumably only build the thing once anyway during an install so it won't
make any difference to them?
John.