From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-05-31 01:41:53
Gennadiy Rozental wrote:
> As you can imagine I would very much prefer to have independent per project
> tree. Something along these lines:
> and so on.
> I don't see why svn structure should reflect the one we use for delivery. I
> also don't see why we need notion of sandbox in this scenario. Every library
> gets it's own tree and may or may not be part of accepted boost libraries
Currently the reasons not to do it that way are that it's not the way
Boost has worked politically. 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.
> 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)
> 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. If we want to do that we
either have to redo/adjust the server set up, or wait until SVN
implements the "internals" feature.
So yes, any changes that break up the Boost tree would require
considerable changes to the building and testing infrastructure.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk