Subject: Re: [boost] Header Inclusion practices
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-04-12 01:10:37
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.
> 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.
The current approach permitted a library user to build and run the
examples without adding the library to the boost tree and running b2
headers and without adding an -I switch or environmental variable. But
the downside is that I have these sort of funky path names for included
header files. I would like one to easily be able to install/uninstall a
particular library without the whole b2 headers back and forth. I would
actually be happy with just adding another -I switch for each library I
use directly. Its typically a small number. But that doesn't deal with
the indirectly used boost libraries.
After I move it to the boost subprojects, I can just follow the normal
rules so in practical terms its not a huge issue for this one library.
I'm really questioning the idea of depending on b2 headers and having
the directory structure inside a library include the "boost"
subdirectory - which has no syblings.
> Having said that, as long as the library isn't actually part of the
> Boost distribution yet it might be more convenient to keep relative
> paths (since the headers don't get moved), but it's one more thing that
> needs to be fixed up later.
I won't save anything by fixing it sooner so I'll leave it for last as
I've already a lot to do.