Re: [boost] Fwd: Installing CMake configuration files

Subject: Re: [boost] Fwd: Installing CMake configuration files
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-10-20 19:07:35

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