Boost logo

Boost :

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


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, gregod at, cpdaniel at, john at