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 21:22:12

On 22/07/17 20:00, Peter Dimov via Boost wrote:
> Roger Leigh wrote:
> 
>> > 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.
> 
> I implemented something along those lines. git clone the 
> "feature/pkgconfig" branch of boostorg/boost, and then at the root 
> (after having built b2) issue
> 
>     b2 tools/pkgconfig//stage
> 
> This will stage the .pc files into stage/lib/pkgconfig.
> 
>     b2 tools/pkgconfig//install
> 
> should also work and put them into $(prefix)/lib/pkgconfig.
> 
> This is not a 100% working solution because of some irregular cases such 
> as math, exception, test, stacktrace, and it doesn't contain the 
> external dependencies such as -lrt ot -lbzip2 as I can't retrieve them 
> automatically. But it could be useful nevertheless.
> 
> Note that I'm generating .pc files for the header-only libraries as 
> well, otherwise there's no way to track static -> header-only -> static 
> dependencies properly.

That makes sense.

I've given it a build and taken a look at the .pc files.  Overall it 
looks very promising.  I'll have to do a more rigourous check of the 
depedencies when I have some more free time.

I'm unsure of the use of Requires.private for all dependencies, e.g. for 
filesystem:

     Cflags: -I${includedir}
     Libs: -L${libdir} -lboost_filesystem
     Requires.private: boost_assert = 1.65.0, boost_config = 1.65.0, 
boost_core = 1.65.0, boost_detail = 1.65.0, boost_functional = 1.65.0, 
boost_io = 1.65.0, boost_iterator = 1.65.0, boost_range = 1.65.0, 
boost_smart_ptr = 1.65.0, boost_static_assert = 1.65.0, boost_system = 
1.65.0, boost_type_traits = 1.65.0

The boost_system dependency, for example, is required when linking to 
filesystem dynamically on Linux and BSD because the filesystem headers 
include the system headers, which forces system it to be explicitly 
linked even if you don't use it directly.  The non-library components 
could certainly be private, but does it hurt to have them public?  Are 
there some extra subtleties here?

Other than that, the only minor cosmetic issue I saw was the duplication 
of the version in the description.

Thanks,
Roger