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