Stefan Seefeld wrote:
Jeff Garland wrote:
It sounds like the sandbox libs will eventually become branches of the main repository, so that would entrench the practice of embedding these libraries into an existing tree. Personally I'd prefer to have something where I can keep a pristine distribution and then add new libs by having them in their own tree -- something like:
boost_1_34_0 boost_some_new_lib1 boost_some_new_lib2
I totally agree. Having to branch the whole boost tree in order to add a new project seems very redundant (in different ways). For one, it requires me manually tracking changes in the trunk/, even if my own work is only kept in a (new) subtree.
It's also redundant since users who want to try a sandbox project would essentially need to store (and build !) a separate boost source and build tree just for the sandbox project.
Hadn't even thought of these issues, but they are good points. I was thinking of the case where I didn't even have subversion for the core boost, but an official distribution.
But to build and run the tests/examples in these 'one library trees' means that you'd need to have a way to specify the base distribution to the build system.
Indeed. But that appears to me to be a good idea anyways. We were discussing ways to modularize boost better. Being able to compile specific boost libs in isolation, while referring / using a separate external boost tree for dependencies seemed to be a worthwhile goal (say, for more modular testing).
Totally agree. Jeff