Subject: [Boost-build] Generating CMake package files using Boost.Build
From: Stephen Kelly (hello_at_[hidden])
Date: 2015-11-17 16:49:56
For CMake users, the most convenient way to consume a library is if the
library provides 'package configuration files' which contain imported
targets. Those files are somewhat similar in concept to pkg-config files in
that they specify flags that consumers should use, but the files use the
cmake language and are designed to be consumed only by cmake.
CMake has commands to allow CMake-based buildsystems to easily
export/generate and install such files. As the files are just plain text,
non-CMake buildsystems, can also generate the files so that downstreams
which use CMake get the convenience, without upstream having to depend on
CMake. This is the case with Qt 5, which uses qmake to build, and to
generate CMake files. It is also the case with the LLVM Makefiles
buildsystem which generates CMake package configuration files.
It could be done for Boost.Build too. This has been raised on the Boost
mailing list several times:
Let's talk about whether it is plausible and what it would mean for users.
The task is for Boost.Build to generate files following a naming convention
and install them to
Generating files which work for a build of Boost (before or without
installing) would also not be a problem.
Such a 'config file' would be generated for each static library built by the
build of boost, and one extra config file to represent header-only files
shipped with Boost.
[Aside: Let's not let this discussion become about modularization. Let's
create a solution that can be deployed with Boost as it is organized today]
The generated config file would contain cmake code such as
add_library(boost::log STATIC IMPORTED)
PROPERTY LOCATION @THE_LOCATION@)
PROPERTY INTERFACE_LINK_LIBRARIES @THE_DEPS@)
where @THE_LOCATION@ and @THE_DEPS@ are determined by Boost.Build and
written into the generated file.
With that as a starting point, we can also generate usage requirements such
as include directories, defines and compile flags which the user must use
when linking against the boost library (as a result of how the boost library
is built). We can also generate 'compatibility requirements' so that
attempting to use libraries which have conflicting usage requirements
results in an error at cmake time instead of link time.
The user then writes something like
# CMake finds the BoostLogConfig.cmake file
It is also possible to generate an 'umbrella' config package so that the
user can instead use
find_package(Boost REQUIRED COMPONENTS Log System)
I think a possible TODO list of where to go from here could be
* Create a branch to work on where prototyping can be done
* Generate and install basic config files
* Add features for transitive dependencies and usage requirements
* Find out how packaging and boost releasing system needs to handle the
presence of the new files
* Find out whether to enable the generated files for all libraries in boost
which create binaries to link to, or somehow make it configurable/opt in.
* Rebase/merge the branch
What do you think?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk