Boost logo

Boost :

Subject: Re: [boost] Header Inclusion practices
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-04-12 01:29:19


AMDG

On 04/11/2017 07:10 PM, Robert Ramey via Boost wrote:
> On 4/11/17 4:10 PM, Gavin Lambert via Boost wrote:
>>
>> While I agree with this practice in general, in the specific case of
>> Boost libraries using ../include relative paths is not a good idea, in
>> my view.
>>
>> The problem with this is the way the source is repackaged as a
>> monolithic zip/tarball -- all of the include directories are removed and
>> replaced with a "boost" folder that combines the include directories
>> from all libraries.
>
> I think it's more accurate to say that it creates a directory structure
> of file links which create the appearance of a monolithic boost
> "procuct". b2 headers is the magic command which creates this structure.

  Gavin is correct. Most of us here work from git,
but the actual release archive doesn't use b2 headers.

>>
>> Thus an end user who only uses this zip/tarball version of Boost cannot
>> build your tests/examples without modifying the source to use
>> <boost/...> includes instead -- so this is what you should have used to
>> begin with.
>
> Actually, my whole motivation was for users to be able to build the
> examples and run tests without having to create links to all the headers
> in the main boost directory. b2 headers only does this for libraries
> which have been "installed" into the boost. There is no tool/mechanism
> for doing such a think with non boost libraries.
>

  Boost.Build can technically handle it.
The actual implementation of b2 headers
doesn't care whether the headers are
part of the Boost tree or not. (Of course,
whether that's a good idea is debatable).

In Christ,
Steven Watanabe


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