Re: [boost] Header Inclusion practices

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.

Robert Ramey