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?