Subject: Re: [boost] Directory structure not quite right yet?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-05 19:49:01
Bjørn Roald wrote:
> 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.
Supporting binary distributions is actually a very interesting idea. It
turns out that the only thing that prevents the current bpm to be able to
install a binary distribution is that it requires that a module is
completely contained into a single directory (libs/$module), so it will not
permit the downloaded archive to extract
I could however package the pre-built binaries in libs/$module/stage if I
had the inclination, and then make bpm symlink
libs/$module/stage/lib/libboost_$module_whatever in the exact same manner as
headers are handled.
Food for future thought.
> 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.
That is what it does, yes.
> 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.
Well... I already wrote the code to symlink/junction/hardlink things, so
unless it turns out to create more problems than it solves, I'd rather keep
> 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.
The problem here, as I already mentioned in the other thread, is that the
library Jamfiles will need to be maintained with the correct dependency
information so that the usage-requirements correctly add the required
I am not saying that this will not be a good thing to do, at some
unspecified future point. But I wanted to get things working with minimal
changes to the status quo.
> 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.
It would've been nice for the current structure to have all modules in
modules/ or components/, rather than some in libs/ and some in tools/. As it
is, I have a special case for the 'build' module to be in tools/build. But
as I said, I wanted bpm to work on the current structure. (Well, I did move
the header links to include/, but this was a very easy change because (a)
they are created by bpm and (b) the changes to Jamroot were trivial.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk