# Boost :

Subject: Re: [boost] Directory structure not quite right yet?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2015-01-01 12:10:15

On 01. jan. 2015 17:02, Edward Diener wrote:
> On 1/1/2015 9:50 AM, Peter Dimov wrote:
>> Andrey Semashev wrote:
>>> Note that this does not mean that there will be no such common
>>> directory in users' setups. The equivalent of 'make install' or
>>> package installation can (and I'm sure will, at least for some time)
>>> form the boost directory with all public headers. The location of this
>>> directory is system-specific.
>>
>> Happy New Year :-)
>>
>> Let's assume Windows then. Let's say that the package installer installs
>> libs/this and libs/that into C:\boost-1.57.0, and then does the
>> C:\boost-1.57.0\boost, and the user needs to add C:\boost-1.57.0 to the
>> include path. I say that -I C:\boost-1.57.0\include is better and more
>> consistent with expectations.
>
> +1
>
> Normally software distributions have their header files off some
> directory, usually called "include", from their product's install
> directory. Boost having their header files off of the install directory
> is an anomaly and I concur with Peter that this should be changed for
> better consistency with other software.

I think I am missing the point. Unless libs is renamed src, which I
dislike, the purpose really escapes me. What is the end goal?

As it is, boost headers can be installed in a folder called include by
installers on any platform, there is nothing that prevents that as
things are now, and in fact it is done by several. It is up to whomever
make the packages for the deployment.

I am more in line with Andrey Semashev here in that the goal should be
to fix dependencies between modules to the level we can conveniently get
rid of b2 headers all together. To build and test libraries we should
rather use -I commandline directives for each dependency.

To emulating a deployment structure it make more sense to have a build
target like the current stage target do that in a staging area. b2
already do that for libraries, so why not the includes as well.

Within each module there is already an include, src, test, build
```--