Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-10-20 17:57:25
On 10/19/2018 06:29 PM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
>> Automating the dependencies is harder,
> That's what I thought. :-)
It turns out to be easier than I originally
anticipated. Before we go there, however, I'd
like to discuss whether it's actually the right
thing to do. In particular, I don't want to go
down a path that will get in the way of modular
installation for headers.
# Ideally it should look something like this:
link-directory headers : ../include
: requirements <location>$(BOOST_ROOT)
: usage-requirements <include>$(BOOST_ROOT) ;
alias boost_any : headers /boost/config//boost_config ;
boost-install boost_any ;
A few issues that are going to come up:
- The stage target needs a hard dependency on the headers.
The default behavior for link-directory is to let the
#include scanner trace the headers to stage.
- The install target will need to introspect the headers
target to find the files to copy.
- For the generated cmake files, distinguishing between
the headers of the current library (which should be
represented directly) and the headers of some other
library (which should be represented as a dependency)
is a bit of a pain. Comparing the project of a headers
target with the project of the current install target
will work I think.
- The dependencies found will probably end up being the
transitive closure of all dependencies unless we take
extra measures to reduce them. This isn't technically
wrong, but may result in excessively long lists.
- We have to assume that the library targets are defined
in the same project that has the stage/install targets.
For instance, putting the actual library targets
in a subproject and making an alias in build/Jamfile
will break badly. This is probably the biggest issue
I have, as I think that implicit behavior based on
targets being in the same project is unintuitive and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk