Boost logo

Boost :

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?
>> 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:

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at