Boost logo

Boost :

Subject: [boost] <link>header?
From: Peter Dimov (lists_at_[hidden])
Date: 2018-01-22 03:17:00


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.

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.)

<link>source is kind of best of both worlds, as it doesn't reparse the
source code each time the library is used, 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.

Comments?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk