Re: [boost] RFC: Separating Boost.Python from Boost

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]>
> wrote:
>
>> 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'm not sure if I understand your assertion.. As we've had this <
> http://www.boost.org/development/requirements.html#Directory_structure>
> 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 
libraries ?

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