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.)
<snip> 3. Old-school buildable libraries. These have a dependency on /boost/headers.
4. Newfangled buildable libraries. These enumerate all of their dependencies in their Jamfile, including type 2 header-only ones. If they use no type 1 libraries, they don't need a dependency on /boost/headers, and don't need the header links.
I mostly agree with you, except for one issue: This is severely complicated by the fact that the dependency on headers is currently implicit. How are we going to distinguish (3) from (4)? If we're making incremental updates, then we can't make any changes at all to the old-school libraries, so we can't rely on them telling us that they need /boost/headers. If we leave the dependency on /boost/headers alone, then type (4) libraries will still pick it up and we'll lose any ability to test that the dependencies listed are sufficient. In Christ, Steven Watanabe