Moving the include directory to $BOOST_ROOT/include? (again)

Peter Dimov

31 May 2015 31 May '15

12:30 p.m.

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include. This has the following benefits: - it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now, - when building Boost, the message given at the end would be The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib instead of the current The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib which is more in line with a user's expectations. - it's more consistent because it builds the virtual include/ subdirectory from the contents of the multiple libs/*/include/ subdirectories. For backward compatibility, "b2 headers" could create a boost/ symlink to include/boost/. Also for backward compatibility, monolithic releases can continue to ship the headers in boost/ if moving the directory would be seen as too disruptive. Failing acceptance of the above proposal, can we at least use a path constant (BOOST_INCLUDE?) somewhere in Jamroot or boostcpp.jam that identifies where the header links are to be placed? Its current contents would be "." but I would be able to change that to "include" instead of locating and patching all the places that refer to the include path.

Show replies by date

Tom Kent

2 Jun 2 Jun

12:59 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases. I think this is far too disruptive of a change for the benefits described. Tom [1] http://www.boost.org/doc/libs/1_58_0/more/getting_started/windows.html [2] http://www.boost.org/doc/libs/1_58_0/more/getting_started/unix-variants.html

Vladimir Prus

6:24 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

On 6/2/2015 3:59 AM, Tom Kent wrote:

...

On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...
I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

I think this is far too disruptive of a change for the benefits described.

Tom, I think the suggestion is to have $BOOST_ROOT/include/boost, so no changes in the source code will be required. You will need a change to the -I option passed to the compiler, which is non-zero pain, but considerably less pain that changing every source file. - Volodya

Andrey Semashev

7 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

On Tue, Jun 2, 2015 at 9:24 AM, Vladimir Prus wrote:

...

On 6/2/2015 3:59 AM, Tom Kent wrote:

...
On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...
I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

I think this is far too disruptive of a change for the benefits described.

Tom,

I think the suggestion is to have $BOOST_ROOT/include/boost, so no changes in the source code will be required. You will need a change to the -I option passed to the compiler, which is non-zero pain, but considerably less pain that changing every source file.

Also the proposal mentioned the $BOOST_ROOT/boost link for backward compatibility, so even the -I option is not necessary. FWIW, I support the proposal.

Tom Kent

3 Jun 3 Jun

12:02 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

On Tue, Jun 2, 2015 at 1:24 AM, Vladimir Prus wrote:

...

On 6/2/2015 3:59 AM, Tom Kent wrote:

...
On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

I want to reiterate my suggestion that we move Boost's include directory

...
from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

I think this is far too disruptive of a change for the benefits described.

Tom,

I think the suggestion is to have $BOOST_ROOT/include/boost, so no changes in the source code will be required.

Ahh, that is not what I got from my first reading of the original message, but re-reading I can see how that would be possible. To be clear we are talking about moving $BOOST_ROOT/boost to $BOOST_ROOT/include/boost correct? If this is the case, I'm fine with that. I have no problem updating my visual studio include path...I would have a problem changing my source files (if something like #include -> #include was required. The only down side I see to this, is then we have this silly include directory with only a single subfolder and no files in it....but that's not the end of the world. Tom

Paul A. Bristow

2 Jun 2 Jun

9:27 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Kent Sent: 02 June 2015 02:00 To: Boost Developers List Subject: Re: [boost] Moving the include directory to $BOOST_ROOT/include? (again)

On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...
I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

I think this is far too disruptive of a change for the benefits described.

+1 It would seem to require changes to every single Visual Studio Project. The decision time for this has passed IMO. We need a long period of stability after the Great Gitification. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Pete Bartlett

3 Jun 3 Jun

6:47 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

...

It would seem to require changes to every single Visual Studio Project.

Others have already pointed out that the symlink makes changing the -I unnecessary, but even it were necessary it seems unlikely to be a huge deal for most people. You'd imagine most do not manage large numbers of project files individually but rather use CMake/Boost.Build/scons/Visual Studio's property sheets to manage them centrally.. I also like the change.

Paul A. Bristow

8:17 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Pete Bartlett Sent: 03 June 2015 07:48 To: boost@lists.boost.org Subject: Re: [boost] Moving the include directory to $BOOST_ROOT/include? (again)

...

...
It would seem to require changes to every single Visual Studio Project.

Others have already pointed out that the symlink makes changing the -I unnecessary, but even it were necessary it seems unlikely to be a huge deal for most people. You'd imagine most do not manage large numbers of project files individually but rather use CMake/Boost.Build/scons/Visual Studio's property sheets to manage them centrally..

One would now - but what about the millions of projects built before Property pages were introduced? Paul PS And yes - having library files in boost/stage/lib is bizarre. All this should have been sorted out as part of modularization - but it was such a struggle to get it to work at all, I can understand why is wasn't.

Peter Dimov

2 Jun 2 Jun

10:18 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include?(again)

Tom Kent wrote:

...

On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...
I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

The idea is that you'd change your include path to reference $BOOST_ROOT/include, without changing a line of code. I've been using this environment for a while and haven't encountered any breakages.

Paul A. Bristow

1:28 p.m.

New subject: Moving the include directory to $BOOST_ROOT/include?(again)

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 02 June 2015 11:19 To: boost@lists.boost.org Subject: Re: [boost] Moving the include directory to $BOOST_ROOT/include?(again)

Tom Kent wrote:

...
On Sun, May 31, 2015 at 7:30 AM, Peter Dimov wrote:

...
I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

Our organization has been following the example in the first pages of the getting started guide [1][2] and using #include with $BOOST_ROOT in our include path, so changing that to 'include' would require major source changes to our (and presumably lots of others') code bases.

The idea is that you'd change your include path to reference $BOOST_ROOT/include, without changing a line of code.

I've been using this environment for a while and haven't encountered any breakages.

What about all the existing Visual projects and solutions? I worry that even your extra environment variable for 'legacy stuff' will cause trouble. 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. I'm still struggling to understand the value of the benefits, compared with those risks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Peter Dimov

1:57 p.m.

New subject: 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?

...

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

...

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. :-)

...

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

Paul A. Bristow

2:59 p.m.

New subject: Moving the include directoryto $BOOST_ROOT/include?(again)

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 02 June 2015 14:57 To: boost@lists.boost.org 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?

...

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

So why wasn't that done to start with? 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.

...

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

OK - but why wasn't that done before? 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

Gavin Lambert

3 Jun 3 Jun

7:40 a.m.

New subject: Moving the include directoryto $BOOST_ROOT/include?(again)

On 3/06/2015 01:57, Peter Dimov wrote:

...

Paul A. Bristow wrote:

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

Unfortunately this is not the case, as symlinks are Complicated™ on Windows and don't work by default out of the box. Personally, I don't mind changing every project, because I don't actually have to change every project, I just have to change the "UseBoost" common property sheet I use in every project instead. :) (But I suspect that's not the case for most.)

Peter Dimov

9:43 a.m.

New subject: Moving the include directoryto$BOOST_ROOT/include?(again)

Gavin Lambert wrote: On 3/06/2015 01:57, Peter Dimov wrote:

...

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

Unfortunately this is not the case, as symlinks are Complicated™ on Windows and don't work by default out of the box.

I say "symlink" for brevity but on Windows in the common case it will probably be a junction.

Tom Kent

10:46 p.m.

New subject: Moving the include directoryto$BOOST_ROOT/include?(again)

On Wed, Jun 3, 2015 at 4:43 AM, Peter Dimov wrote:

...

Gavin Lambert wrote: On 3/06/2015 01:57, Peter Dimov wrote:

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

Unfortunately this is not the case, as symlinks are Complicated™ on Windows and don't work by default out of the box.

I say "symlink" for brevity but on Windows in the common case it will probably be a junction.

I don't think either works reliably on Windows. They will only work if group policy permits it (and symlinks will never work on win7 if you are an admin, ironically) and lots of programs don't deal with junctions correctly. I'd rather just make the change and force the update to projects' include path than having symlinks/junctions hanging around for backwards compatibility. If users want to add a symlink/junciton, they can do that. Tom

Peter Dimov

10:59 p.m.

New subject: Moving the includedirectoryto$BOOST_ROOT/include?(again)

Tom Kent wrote:

...

On Wed, Jun 3, 2015 at 4:43 AM, Peter Dimov wrote:

...
I say "symlink" for brevity but on Windows in the common case it will probably be a junction.

I don't think either works reliably on Windows. They will only work if group policy permits it (and symlinks will never work on win7 if you are an admin, ironically) and lots of programs don't deal with junctions correctly.

"b2 headers" currently creates junctions when symlinks aren't available (which is basically always) and I haven't had problems with them so far.

Paul A. Bristow

4 Jun 4 Jun

9:30 a.m.

New subject: Moving the includedirectoryto$BOOST_ROOT/include?(again)

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 04 June 2015 00:00 To: boost@lists.boost.org Subject: Re: [boost] Moving the includedirectoryto$BOOST_ROOT/include?(again)

Tom Kent wrote:

...
On Wed, Jun 3, 2015 at 4:43 AM, Peter Dimov wrote:

...
I say "symlink" for brevity but on Windows in the common case it will probably be a junction.

I don't think either works reliably on Windows. They will only work if group policy permits it (and symlinks will never work on win7 if you are an admin, ironically) and lots of programs don't deal with junctions correctly.

"b2 headers" currently creates junctions when symlinks aren't available (which is basically always) and I haven't had problems with them so far.

I have, requiring deletion of the /boost folder and rebuilding. Also running with admin privs, or not, is an unwelcome complication. (I start my DOS box using a (not-entirely-obvious) shortcut that runs with admin privs, but I'm not sure if that is the best idea). Sadly, it is all more complicated than would be ideal. However, if people want a $BOOST_INCLUDE environment variable, then that's fine with me. Just please don't *make* people change the source or folders or build system they have now! Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Andrey Semashev

7:19 a.m.

New subject: Moving the include directoryto$BOOST_ROOT/include?(again)

On Thu, Jun 4, 2015 at 1:46 AM, Tom Kent wrote:

...

On Wed, Jun 3, 2015 at 4:43 AM, Peter Dimov wrote:

...
I say "symlink" for brevity but on Windows in the common case it will probably be a junction.

I don't think either works reliably on Windows. They will only work if group policy permits it (and symlinks will never work on win7 if you are an admin, ironically) and lots of programs don't deal with junctions correctly.

Junctions worked very well for me since Windows 2000, I've never had any problems with them.

Bjørn Roald

3 Jun 3 Jun

6:38 a.m.

On 31. mai 2015 14:30, Peter Dimov wrote:

...

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include.

This has the following benefits:

- it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now,

how exactly are planning to make that work when it seems you still plan on keeping the current "b2 headers" machinery as the mechanism that put files (links) in $BOOST_ROOT/include? If you plan to support building the content of $BOOST_ROOT/include with copies using something like "b2 stage" I do understand and I am more inclined to be in favor of a change like this.

...

- when building Boost, the message given at the end would be

The Boost C++ Libraries were successfully built!

The following directory should be added to compiler include paths:

C:\Projects\boost-git\boost\include

The following directory should be added to linker library paths:

C:\Projects\boost-git\boost\stage\lib

So if you go ahead with this, and while you are at it, why not stage the libs to $BOOST_ROOT/lib rather than $BOOST_ROOT/stage/lib. As this change is motivated by following the "established" naming practice then I think the stage folder is a rather odd thing for the library path, given that the include path is not in the stage folder? As far as how b2 should support this, the "b2 stage", which now seem to be default when you just type b2, should create (stage) a monolithic view of your selected parts of boost in: $BOOST_ROOT/include $BOOST_ROOT/lib Which I think is much better than $BOOST_ROOT/include $BOOST_ROOT/stage/lib Having said that, conceptually I like the stage step as a build step and the stage folder as a staging area within $BOOST_ROOT of what will be installed somewhere else if you use "b2 install --prefix=PREFIX", with this as a concept the message at the end of the build could be: The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\stage\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib Use ./b2 install --prefix=PREFIX to install boost elsewhere. I realize that this is sort of swimming against the current here and I am not going to argue any more for it unless it gain significant support from others. Remember, before header files where moved to $BOOST_ROOT/libs/*/headers they lived in $BOOST_ROOT/boost and there where no need to stage them in $BOOST_ROOT/stage like the libraries had to be staged. Then we invented "b2 headers" as a band aid to keep the $BOOST_ROOT/boost structure alive as a proxy to support internal use of header files between boost libraries the same as before. As a side effect boost users that preferred to build boost themselves and opted to not use "b2 install" could still use $BOOST_ROOT/boost. I think that is unfortunate, maybe we should have hidden the header links somewhere out of sight as long as they where needed, maybe within $BOOST_ROOT/bin.v2 and done what we are discussing now with proper copies for external use in the first place. Possibly as part of a modified "b2 stage" target. I think it is vise to plan for b2 headers linking mechanism to eventually go away, as boost libraries hopefully will be able to build themselves without using a monolithic view of all boost headers, rather use headers in needed in libs/*/include directories directly during the build. Side note: I hope all references to $BOOST_ROOT above for anything derived during the build, will be redirected with b2 --build-dir. So when I e.g.: refer to $BOOST_ROOT/include it is in fact an include folder in the build directory. -- Bjørn -- Bjørn

Gavin Lambert

7:50 a.m.

New subject: Moving the include directory to $BOOST_ROOT/include? (again)

On 3/06/2015 18:38, Bjørn Roald wrote:

...

Having said that, conceptually I like the stage step as a build step and the stage folder as a staging area within $BOOST_ROOT of what will be installed somewhere else if you use "b2 install --prefix=PREFIX", with this as a concept the message at the end of the build could be:

The Boost C++ Libraries were successfully built!

The following directory should be added to compiler include paths:

C:\Projects\boost-git\boost\stage\include

The following directory should be added to linker library paths:

C:\Projects\boost-git\boost\stage\lib

Use ./b2 install --prefix=PREFIX to install boost elsewhere.

+1. It seems weird to not have "include" and "lib" in the same place, so if a staging dir is how Boost wants to build its libraries, it should do the same thing for the headers, especially since they're getting copied/linked from the library subdirs anyway.

...

As a side effect boost users that preferred to build boost themselves and opted to not use "b2 install" could still use $BOOST_ROOT/boost. I think that is unfortunate, maybe we should have hidden the header links somewhere out of sight as long as they where needed, maybe within $BOOST_ROOT/bin.v2 and done what we are discussing now with proper copies for external use in the first place. Possibly as part of a modified "b2 stage" target.

I would prefer if the "b2 install" step were still optional, but I don't see this as a problem as users could just refer to $BOOST_ROOT/stage/include and $BOOST_ROOT/stage/lib, exactly as shown in the proposed message above. (Or the user could manually copy just the stage folder elsewhere to "install" it -- provided that it didn't contain any symlinks, which is a fairly safe bet on Windows.)

3465

Age (days ago)

3469

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Andrey Semashev
Bjørn Roald
Gavin Lambert
Paul A. Bristow
Pete Bartlett
Peter Dimov
Tom Kent
Vladimir Prus