Subject: Re: [boost] Installing CMake configuration files
From: Peter Dimov (lists_at_[hidden])
Date: 2018-10-16 03:20:16
Louis Dionne wrote:
> Would it be possible to have one Boost::XYZ library for each header-only
> library XYZ?
It's possible in principle; my first iteration did have targets for all
libraries. I'd however prefer to get a release out using this scheme first,
to see how it fares in the field.
There are several possible approaches we could adopt if we want targets for
all libraries, and the one I like is to go full modular and add
build/Jamfiles to header-only libraries, with stage and install targets that
link/copy the headers. So that you could `b2 --prefix=~/.local install-hana`
from top level and get, in ~/.local/include, Hana's headers and the headers
of its dependencies, and in ~/.local/lib/cmake, the config files of same.
For this to work, we need to change our releases to no longer delete
libs/$lib/include, as I mentioned.
Also, we need to fix our circular dependencies. This may take a while. :-)
It's not clear whether all this will be worth doing if we're going to move
to a CMake-based installation though.
> Those would just include the headers by default, however it has the
> following benefits from the user side:
> 1. If a library stops being header-only, user code still works and will
> automatically start linking against the right library when the CMake
> Config file is updated.
> 2. It allows providing compile options or required compile features via
> the imported target. For example, I may want someone "linking" against
> Boost::hana to get `-Wno-user-defined-literal` automatically (I don't, but
> you get the idea).
How are you going to communicate your target_compile_definitions (or
whatever) to the code generating the config file? Perhaps you'll have a
ready-made config file that would be installed instead of the generated one?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk