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

On 5/31/2015 12:59 AM, Rene Rivera wrote:

On Sat, May 30, 2015 at 11:48 PM, Edward Diener wrote:

...

On 5/31/2015 12:20 AM, Rene Rivera wrote:

...

On Sat, May 30, 2015 at 3:37 PM, Steven Watanabe 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.