Re: [boost] Directory structure not quite right yet?

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
>> equivalent of "b2 headers". The header links go into
>> 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 
directory structure.  The b2 headers staging of headers to the boost 
folder was just to ease the transfer to the git modules and is a 
temporary solution -- hopefully.

--
Bjørn