AMDG 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: alias boost_any : /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. In Christ, Steven Watanabe