Re: [boost] questions regarding dependency reports(s)

Subject: Re: [boost] questions regarding dependency reports(s)
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-09-27 03:36:30

On 09/27/2014 07:20 AM, Robert Ramey wrote:
> Edward Diener-3 wrote
>> While processing headers is worthwhile, I do not believe that any
>> dependency system relying just on that technique will ever be able to
>> always determine all the dependency information necessary to isolate a
>> library and its dependencies for every potential use case. It may work
>> for a very simple situation but will not scale as a library gets more
>> complicated and offers a number of choices how it can be used. Boost
>> ideally will need something better based on some sort of
>> meta-information which a library author will need to supply.
>
> What would this meta information include?
>
>> Of course if there is no real impetus to provide Boost library isolation
>> and Boost will continue to be distributed in its current monolithic way,
>> then the tracking of dependencies via header file analysis may be as
>> adequate as we want to get to a decent indication of what depends on what.
>
> I would like to see Boost be able to grow to 500 libraries in the next 10
> years.
>
> Requiring a user to download/install 500 libraries to use the one he want's
> doesn't seem convincing to me.
>
> You've all convinced me that no completely automated approach will
> do the job.
>
> So I'm sort of stumped.   Maybe we can make this work by a couple
> of simple things
>
> a) enhance BCP so that the top level dependent doesn't have to be
> a library but could be an application.  This would mean that a user
> no interested in tests or examples could just get a list of the the
> dependencies for his application or perhaps just the library build itself.

It is an attractive idea. However, here is a concern that should be 
considered. With any sort of packaging or other partial distribution I 
worry about how discovery of yet-to-use parts are facilitated for the 
user.  Such discovery facilitation may degrade further with a 
potentially very fine grained bcp "just copy what you use" strategy to 
deployment.  A very simple example is that you can use IDE editors to 
find the correct name of an include file, but if it is not there yet, 
this will simply not work.  Certainly a coarse distribution of this 
information may be better, but hopefully there is better ways than all 
of boost itself in one monolithic package.  One approach would be to 
build some sort of meta-data package information for all of boost that 
tools could use to let users discover, explore and include unused 
elements of boost with ease.

--
Bjørn