On 7 Oct 2014 at 15:44, Vinícius dos Santos Oliveira wrote:
Said libraries need to be header only, so no build system needed. Makes things much simpler.
Agreed. But what about unit tests?
Nothing in this fork effort stops you still using the exact same library within Boost, it just replaces Boost with the STL when standalone. Hence you'd still run the unit tests there. If you want unit testing capable of testing the standalone build, I am working on some macro shims based on CATCH which emulate Boost.Test. They won't be entirely equivalent though as CATCH isn't threadsafe (basically we won't call catch unless the test fails, so non-failing tests aren't logged). Library maintainers will have to port their unit test framework over, plus add cmake/Makefile as appropriate where necessary for standalone unit testing. Or hack their Jamfile, and have a standalone build tested from within Boost. Up to the maintainer.
And how do we will install these libraries on the systems?
git submodule add to your project.
Will the solution be embedding local versions of the libraries in the app?
You could, but adding it as a git submodule will probably be easier. My "custom build" script I expect to be a thin veneer of github's ability to zip git repos for you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/