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