Re: [boost] Moving the include directoryto $BOOST_ROOT/include?(again)

Subject: Re: [boost] Moving the include directoryto $BOOST_ROOT/include?(again)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-06-02 10:59:11

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Peter Dimov
> Sent: 02 June 2015 14:57
> To: boost_at_[hidden]
> Subject: Re: [boost] Moving the include directoryto $BOOST_ROOT/include?(again)
> 
> Paul A. Bristow wrote:
> 
> > I'm still struggling to understand the value of the benefits, compared
> > with those risks.
> 
> You don't see how unusual it is to have the include directory point to the root of the
distribution, instead
> of pointing to a directory with header files, as is the case with Everything Else?

So why wasn't that done to start with?
 
> > > I've been using this environment for a while and haven't encountered
> > > any breakages.
> >
> > What about all the existing Visual projects and solutions?
> 
> All existing Visual Studio projects and solutions, and everything that still points its include
directory to the
> Boost root, will (should) continue to work because of the symbolic link from $BOOST_ROOT/boost ->
> $BOOST_ROOT/include/boost, which I've proposed for this purpose.

Will that double the symlinks?

> > I worry that even your extra environment variable for 'legacy stuff'
> > will cause trouble.
> 
> I don't see how, given that I'll probably be the only one using it. :-)

Ok :-)

> > Having been told by David Abrahams that environment variables are
> > evil, and getting rid of $BOOST_ROOT references, it now seems that
> > they will be essential.
> 
> Projects that put $BOOST_ROOT in their -I path do that because they try to support a structure in
which
> their directory is not under $BOOST_ROOT. I'd argue that for such projects using $BOOST_INCLUDE
> instead is more correct and more descriptive.

OK - but why wasn't that done before?
 
> Projects that refer to ../../../.. would do nothing while we continue shipping the headers in
boost/ in
> monolithic releases. If we change releases to ship headers in include/boost/ or to not ship
headers in a
> central location but require a "b2 headers" step, those projects will have to be changed to refer
to
> ../../../../include.

It's also this that worries me - there are a lot of jamfiles!  And not just in Boost.

But let's hear from others - I've already given more than enough of my pennyworth(s).

Paul