On 10/4/17 10:36 AM, Stefan Seefeld via Boost wrote:
On 04.10.2017 13:22, Rene Rivera via Boost wrote:
For one, I didn't mean to re-open a discussion about separating release cycles. I merely wanted to point out a limitation in the existing Boost.Build logic, and how I hope that any future build system will support stand-alone builds, so further modularization can at least be considered and experimented with.
Not entirely sure what you are referring to... But B2 doesn't have such a limitation. So perhaps I missed something something.
Perhaps b2 the tool doesn't have such a limitation, but b2 the boost build infrastructure does, given that it's impossible to build library Boost.X stand-alone, i.e. without starting from the superproject repo.
Hmmm - I'm not seeing this. I always build all my tests from the serialization/test directory. This also automagically builds all the precursor libraries like boost/system etc. So the current setup gives me what I expect and desire in this regard.
I'm pretty sure that could be fixed quickly for someone with the required knowledge, but right now that's not a supported workflow. Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.
Correct. We have several intertwined issues: a) Build/test of boost libaries b) Posting of test results c) Dependencies d) Deployment e) import of boost libraries (modules) by users Which bring up other issues such as per library versioning, b2 headers and the like. It's going to be pretty tough to keep this discussion from getting too confusing. Robert Ramey
Stefan