Re: [boost] <link>header?

Subject: Re: [boost] <link>header?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-01-22 03:50:54

AMDG

On 01/21/2018 08:17 PM, Peter Dimov via Boost wrote:
> While refactoring the test Jamfile for Boost.System, I wrote this rule:
> 
> rule system-run- ( sources + )
> {
> Â  local result ;
> 
> Â  result += [ run $(sources) : : : <link>static : $(sources[1]:B)_static
> ] ;
> Â  result += [ run $(sources) : : : <link>shared : $(sources[1]:B)_shared
> ] ;
> Â  result += [ run $(sources) : : : -<library>/boost/system//boost_system
> <define>BOOST_ERROR_CODE_HEADER_ONLY : $(sources[1]:B)_header ] ;
> 
> Â  return $(result) ;
> }
> 
> to avoid repeating each test three times.
> 
> The inconsistency is somewhat annoying. We could normalize the third
> line by introducing a third link type, <link>header, in response to
> which the library can switch to header-only mode.
> 
> This is more or less the same suggestion as Niall's _hl targets from the
> CMake discussion, but it fits Boost.Build better, because the <link>
> property is automatically propagated to dependencies.
> 

  So the question is what should <link>header do for
libraries that do not have a header-only mode?

> 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.  What you're
describing sounds like it should be:

alias boost_system : error_code.cpp : <link>source ;

> <link>source is kind of best of both worlds, as it doesn't reparse the
> source code each time the library is used,

  This isn't exactly true.  It will reparse
the source once in each project that uses it.
It will also reparse it in each test case
that uses it, since test cases get independent
build directories.

> and at the same time is not
> prone to the ODR violations introduced by inadvertently compiling the
> library and the executable with different, ABI-incompatible options.
>

  At least you won't get silent errors, but this is
highly likely to cause errors from Boost.Build if
you use a source library in two different executables
in the same project.  (Boost.Build will attempt to share
the object file, but if any defines or cxxflags are
different it will fail).

It should be pretty easy to try this out:

feature.extend link : header ;
feature.extend link : source ;

lib boost_system : error_code.cpp ;
alias boost_system :
  : <link>header
  :
  : <define>BOOST_SYSTEM_HEADER_ONLY
  ;
alias boost_system : error_code.cpp
  : <link>source
  ;

In Christ,
Steven Watanabe