[boost] Configuration framework (Was: [Regex] Building Boost.Regex with ICU)

Subject: [boost] Configuration framework (Was: [Regex] Building Boost.Regex with ICU)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-09-21 14:06:13

John Maddock wrote:

>> Small note:
>>
>> Generally it is very simple to do a standard template like:
>>
>>   int main() { return 0; }
>>
>> And it would fail if you would try to link with not-existing library, no
>> need to
>> specify
>>
>> anything unusual. You don't need to call any function explicitly. This is
>> the
>> way autoconf works.
> 
> Nod, and sometimes that works, but I've also been bitten by it not working:
> for example when checking for a C++ library you need to be sure that it's
> ABI is compatible with the code you're building, so actually linking against
> something tangible seems to be the correct thing to do.

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?

- Volodya