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

Subject: Re: [boost] Directory structure not quite right yet?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2015-01-05 21:16:36

On 06. jan. 2015 01:49, Peter Dimov wrote:
> 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.

I am not sure I follow all, but if some future version of bpm support 
pre-built packages then a new user will likely expect

  bpm install filesystem

to install only the include and lib folders with binaries for the 
default toolchain on the download host, as this is what most users need, 
no more, while

  bpm install filesystem-doc filesystem-src filesystem-examples

would install the respective optional extras, Hopefully globing or 
regexp would work so:

  bpm install filesystem*

would instal the lot. I guess it can be turned around, so:

  bpm install filesystem-bin

or something like

  bpm install filesystem-clang-3.5

for clang 3.5 binaries on standard host ABI

I think you may want to give the tools command line convention some 
thought so it retain a growth potential for  future  support for 
handling of binary packages.

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

Are you sure you _copy_ files, I think you say something else further 
down ;-)

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

OK, good luck with that.

>> 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 don't think the maintenance of such dependencies in build files are 
hard, test build would cause errors on missing dependencies. b2 could 
help with dependency analysis and warn on problems and suggest changes. 
Generally it will also raise the level of caution with regard to 
dependency issues, as you actually see somewhere an explicit mention in 
your module og the other modules you depend directly on.
#include <...> are not quite the same as it is not always clear you add 
an extra dependency.  But I guess that is just an opinion.

The bigger question is if time is right for this, it is an interruptive 
thing and a fair bit of jam files need to be modified.  I would think 
unless it would actually help efforts of reducing inter boost 
dependencies, it is better to wait until those dependencies are reduced 
as far as it goes, then this can be reconsidered.

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

100% understood

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

Fair enough, but it sort of escape me why you are so determined to get 
the headers into a conventional "include" directory, on the grounds that 
that is what users expect, while you seem perfectly fine with keeping 
the libraries hidden inside a very unconventional "stage" directory. 
What other project or software distribution use a "stage" directory? I 
can not think of one.

> But as I said, I wanted bpm to work on the current
> structure.

Why?  It is not like that structure exist before bpm download files.  So 
there is no current structure to work on.  Am I missing something?

--
Bjørn