On 04. jan. 2015 16:48, Peter Dimov wrote:
Bjørn Roald wrote:
What is the end goal?
That was, and remains, a very good question.
The end goal is a tool 'bpm' that can do this:
D:\tmp3>bpm install filesystem bpm: installing module 'filesystem' bpm: installing module 'assert' bpm: installing module 'config' bpm: installing module 'core' bpm: installing module 'detail' bpm: installing module 'functional' bpm: installing module 'io' bpm: installing module 'iterator' bpm: installing module 'range' bpm: installing module 'smart_ptr' bpm: installing module 'static_assert' bpm: installing module 'system' bpm: installing module 'type_traits' bpm: installing module 'mpl' bpm: installing module 'preprocessor' bpm: installing module 'function' bpm: installing module 'function_types' bpm: installing module 'integer' bpm: installing module 'optional' bpm: installing module 'typeof' bpm: installing module 'utility' bpm: installing module 'concept_check' bpm: installing module 'conversion' bpm: installing module 'tuple' bpm: installing module 'array' bpm: installing module 'regex' bpm: installing module 'align' bpm: installing module 'predef' bpm: installing module 'throw_exception' bpm: installing module 'bind' bpm: installing module 'move' bpm: installing module 'build' bpm: the following libraries need to be built: filesystem regex system bpm: (use ./b2 to build) bpm: recreating header links
which should be self-explanatory.
When it says "installing module 'foo'", it means "downloading libs/foo" (except for build, where it downloads tools/build and a few other files.)
I like the intentions here. I think having a platform agnostic tool for source level packet management is a good way to go. I would be more skeptical if you intended make the next generic packet manager from scratch for binary distribution. It is just too complex, and there are too much competition too have a reasonable chance of getting wide adaption. That said, useful meta data from boosdep, bpm, b2, etc., with some HOWTOs, could make life better for boost packet maintainers trying to make good binary distributions of boost for various platforms. A few opinions: A source packet manager, like bpm, should copy headers from the installed modules' into the $BOOST/include/boost directory. The bpm tool should not depend on headers in $BOOST/boost, nor depend on ./b2 for staging headers in $BOOST/boost or $BOOST/include/boost. Further bpm should avoid any symbolic link, junction, or hard link trickery like "b2 headers" attempts, it is just too tricky to do right for everyone, in particular automated symbolic link creation on Windows is hard and just not worth it. We are talking about an installation, so keep it simple. For the b2 build I would suggest changing jam files so b2 is specifying a -I for each module the build depend on, rather than a single -I $BOOST/include to where bpm staged the headers. That will keep the two tools independent of each other. I would also like to suggest having bpm install all modules, including build in a "modules" folder together with a custom bootsstrap and set of Boost.Build project root files, and stage libraries in a "lib" folder rather than stage/lib. -- Bjørn