Re: [boost] <link>header?

Subject: Re: [boost] <link>header?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-01-22 16:37:31

AMDG

On 01/22/2018 05:31 AM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
> 
>> So the question is what should <link>header do for libraries that do
>> not have a header-only mode?
> 
> Fall back to <link>static, I suppose.
> 

Okay.  So that means that a library with a header-only
mode has to look like:

lib boost_xxx : source.cpp ;
alias boost_xxx : : <link>header : : <define>HEADER_ONLY ;
# If you leave out the alias, <link>header becomes
# equivalent to <link>static.  It will still create
# a separate build directory and propagate <link>header
# to dependencies.

and not:

lib boost_xxx : source.cpp : : : <link>header:<define>HEADER_ONLY ;
# This seems like the obvious extension of the
# way <link>shared is handled, but it won't quite work.
# If we allow this, and the library does not support
# header-only, it will silently disappear, because
# Boost.Build has no way to identify whether header-only
# is actually supported or not.

>> > Furthermore, after thinking about it a bit, I think that we might
>> even > have room for a fourth link type, <link>source, in response to
>> which the > library target would pass an appropriate <source>
>> usage-requirement > upwards. (<source>error_code.cpp in Boost.System's
>> case.)
>>
>> Â  You don't need usage requirements for this, and it's not quite the
>> right thing either, as it will continue to propagate up past any
>> linking steps.
> 
> I think that it's exactly what I want (although I haven't yet tried it
> out.) If we take the example at which you hint later:
> 
> exe x1 : x1.cpp boost_system : <cxxflags>-std=c++03 <define>FOO ;
> exe x2 : x2.cpp boost_system : <cxxflags>-std=c++11 <define>BAR ;
> 

This will fail with a hard error.
Duplicate name of actual target: bin/gcc-n.n.n/debug/error_code.o
added properties: <cxxflags>-std=c++11 <define>BAR
removed properties: <cxxflags>-std=c++03 <define>FOO

(Note: I think that attempting to share object
files between main targets is a mistake, but
fixing it would require adding yet another
directory to the target paths, even though it's
usually not needed)

> a <source>error_code.cpp usage requirement will result in x1 and x2
> getting their own copy of error_code.cpp, each compiled with the
> respective cxxflags and defines. Right?
> 

What I was talking about here is:

# This also sees error_code.cpp as a source
stage install : x1 : <location>stage/bin ;

In Christ,
Steven Watanabe