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
stage/lib/libboost_$module_whatever.
I could however package the pre-built binaries in libs/$module/stage if I
had the inclination, and then make bpm symlink
stage/lib/libboost_$module_whatever to
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
it. :-)
> 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
include directories.
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.)