Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Roger Leigh (rleigh_at_[hidden])
Date: 2017-07-22 11:18:24

On 22/07/17 11:47, Peter Dimov via Boost wrote:
>> Roger Leigh wrote:
>>
>> > This is what we do in the absence of proper dependency information 
>> being > provided by Boost, i.e. no pkg-config, cmake config or 
>> similar.  We > hard-code *every* *single* *dependency* from 1.33 up to 
>> 1.64 at the time > of writing.
>>
>> Why didn't you ask here for us to include dependency information into 
>> the release?
>>
>> http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do 
>> all sorts of dependency reports and I'm actively maintaining it, I've 
>> recently even added a cmake-specific output as I needed that to 
>> generate the -config files.
> 
> This is a serious question, Roger. I'm not trolling you or something.
> 
> We obviously can't roll back time so this is water under the bridge, but 
> I'm still interested in your answer. You can be as blunt or explicit as 
> you like.

Terrible to say, but my memory is failing me, and I can't remember!  I'm 
pretty sure I did look at it, but there was some reason why I didn't 
find it a match for FindBoost's needs at the time, but I can't recall 
the specifics.

I ended up writing this; it's in a CMake script, so it's a bit verbose:

https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Scripts/BoostScanDeps.cmake

One thing the script does to is special-case a number of situations 
where a header of one component is actually a separate component in its 
own right, mainly related to python, mpi and serialization.  It's also 
special-cases the zlib/bzip2 autolink stuff so we don't use the 
windows-specific data on other platforms.  These might have been part of 
the reason, but I'm not entirely certain.

Again not remembering exactly, but the mappings we have in FindBoost 
right now are not exactly boost component interdependencies but 
shared/static library interdependencies only, based on the autolink 
data.  That might also have been part of the reason.

I'd expect that with Boost providing per-component configuration files, 
this could be greatly improved to cover every component irrespective of 
whether or not it provides a library (or libraries).

> Similarly, the pkg-config one. I'm genuinely interested in how 
> pkg-config support, if we have it, is supposed to handle multiple build 
> variants having been installed.
> 
> I've already solved that for the cmake -config files, but I'm not sure I 
> see a way for pkg-config to support it.

It's been a while since I looked at this, but my understanding is that 
it can't by design.  You have one variant installed, with a matching set 
of pkg-config files which point to those libraries.

If you need multiple variants, you need to install each variant into a 
separate prefix and then configure pkg-config (via an environment 
variable) to search the desired prefix.

This is a case where Boost's policy of appending all of the 
toolset/configuration/threading model etc. to the library name is 
somewhat unique and, and generally incompatible with how the rest of the 
world works.  In general, I've found it a hindrance to interoperability, 
and solving a problem which I didn't have in the first place.  No one 
else does it, and there's likely a good reason for that!  At most, I add 
a 'd' debug postfix on Windows, and that's it (this is handled by CMake 
as a standard behaviour).  If I need multiple configurations, I build 
them separately and explicitly; I don't expect it of the build system 
itself.

Regards,
Roger