Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-10-20 20:22:33
On 10/20/2018 12:19 PM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
>> 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 ;
> I'm not sure we want that. A modular header-only library should have
> usage-requirements <include>../include, not <include>$(BOOST-ROOT) (and
> consequently should not link headers when used as a dependency.)
I'd like to back up a step to my original point,
which is: how is this going to interact with
automatic dependencies for stage and install.
Under this scheme the most obvious way to
handle a header only library is like this:
: /boost/config//boost_config # + other deps
: usage-requirements <include>../include ;
boost-install boost_any ;
This isn't going to work as is, because the
bare <include> is not enough to identify something
that needs to be installed and tracked as a dependency
in the cmake output vs. some external include path.
To make it work we need to give an extra path to
boost-install like this:
boost-install boost_any : ../include ;
Now, boost-install can keep around a global
map tracking which include paths correspond
to which libraries, and we can use that to
sort out the header dependencies.
Note: boost-install could simply assume that
the headers are in ../include, but I strongly
prefer to limit implicit behavior like that.
Okay. I think I've convinced myself that we
can derive the dependencies for libraries without
painting ourselves into a corner, which is what
I was worried about.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk