|
Boost : |
Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-31 00:48:50
On 5/31/2015 12:20 AM, Rene Rivera wrote:
> On Sat, May 30, 2015 at 3:37 PM, Steven Watanabe <watanabesj_at_[hidden]>
> wrote:
>
>> AMDG
>>
>> On 05/30/2015 01:24 PM, Robert Ramey wrote:
>>>
>>> If boost build doesn't do it this way but rather depends upon some list,
>>> well it would be easy for boost build to generate the list from the
>>> directory structure - no other changes necessary.
>>>
>>>
>>> Actually, this would be quite easy for me to implement as as shell
>>> script. I realize that this would repeat some dependency checking but it
>>> would still work. In general, the building of all of boost should be
>>> the union of building each library in the libs directory. Similar for
>>> test.
>>>
>>
>> Building is currently done this way (with a few special
>> cases). The tests have a hard-coded list in status/.
>>
>
> I've wished for some time that was not the case. And that we could do a
> simple glob and automate the set of tested libraries. But the non-flat
> structure of the current arrangement makes that much harder than just
> having a manual list. I've mentioned before that I would very much prefer
> if we didn't have libraries within libraries in the libs structure. As a
> flat structure would make it possible to automate. But library authors have
> ignored my view on this. Note this also make the root build files more
> complicated than they need to be.
This is not a problem if there were an agreement as to the directory
structure of a Boost library in the directory tree. But aside from the
'include' directory structure so that symlinks and 'b2 headers' can be
set up to work correctly I don't believe there is such an agreement.
I do not believe that a flat directory structure is optimal. There are
libraries that should be nested within other libraries if conceptually
this is the case.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk