Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-31 01:27:08
On 5/31/2015 12:59 AM, Rene Rivera wrote:
> On Sat, May 30, 2015 at 11:48 PM, Edward Diener <eldiener_at_[hidden]>
>> On 5/31/2015 12:20 AM, Rene Rivera wrote:
>>> On Sat, May 30, 2015 at 3:37 PM, Steven Watanabe <watanabesj_at_[hidden]>
>>>> 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
>>>> 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
>>> 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'm not sure if I understand your assertion.. As we've had this <
> for, IIRC, at least a decade.
You are right and I am wrong. But then I do not see why you think a
non-flat structure presents problems automating the set of tested
>> 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.
> Please explain in detail and with examples. I truly do want to know why you
> think this.
Because certain libraries are conceptually part of a larger concept, and
I think those libraries being nested within either another library, or a
directory representing the larger concept, is a natural way to represent
them within a directory tree. Forcing the directory tree to be flat does
not seem to me to be necessary. Let's say with the sort library we have
a number of different sort algorithm in the future and each of those
algorithms has its own library of functionality. Why not allow them to
be under a general 'sort' directory for clarity. Using the file
directory structure as a grouping mechanism seems natural to me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk