"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:465E6021.7060407@gmail.com...
Currently the reasons not to do it that way are that it's not the way Boost has worked politically.
What politic do you mean? I am usually politically ignorant, so please be more specific.
And I really don't want to get into such a debate on this thread. If you want to raise the idea of library modularity, again, I would suggest another thread. I'm just trying to drive people into considering what SVN arrangement accommodates our current and historical uses.
My idea of "library modularity" or rather independent library releases is kinda orthogonal. Though obviosly related. It's more has to do with what we put in <lib>/releases and how we deploy boost as a whole. The above svn structure is more natural for my approach - that's true. But it has the value of it's own even with existing build/deployment practice, don't you agree? Among other things it gives nice logical and phisical separation of all the libs with their private branches. And we donlt have to duplicate tree structure for accepted/proposed libs.
The only question is how to build using this structure. We either need to make changes along the lines I pitched before or create reflection tree using externals: (this tree will only include accepted libraries)
boost config-> external reference to config/trunk python->external reference to python/trunk
and so on.
This should allow existing make system work as expected.
Externals, as currently implemented in SVN, and as the Boost svn server is set up, do *not* work in the general case.
I've seen some post in this regard. Could you clarify what the problem is again?
If we want to do that we either have to redo/adjust the server set up,
How difficult is this?
or wait until SVN implements the "internals" feature.
What is "internals" and when can we expect it to be implemented?
So yes, any changes that break up the Boost tree would require considerable changes to the building and testing infrastructure.
I hoped we could split the difference. Move to better (IMO obviosly), independent code structure while keep using existing infrastructure. Eventually we can employ all the power of independent component development. Gennadiy