Re: [boost] Directory structure not quite right yet?

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.)