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

Subject: Re: [boost] questions regarding dependency reports(s)
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-09-27 03:04:18

On 9/27/2014 1: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?

Each configuration of a library could have a separate name, with the 
main configuration being called 'main' let's say. For each configuration 
there would be a list of the library's directories and/or files which 
are needed to use that library along with a list of all direct 
dependencies of the library. The direct dependencies of the library 
would include such information about the dependency such as the library 
name itself, versions of the library which are acceptable, and the name 
of a configuration which is acceptable. Then you go to each direct 
dependency library, with the correct version(s) and configuration and 
recursively find out its dependencies etc.

Each library would need some sort of version number as part of it 
meta-information. Most probably this should be both a general Boost 
version number and an individual library version number.

The idea is for every library to tell you what its direct dependencies 
and files for each of its configurations, and this gets applied 
recursively for each dependent library until a working set of 
directories/files are created which can be downloaded and used for any 
particular library.

The end-user says, I want to use library X with configuration Y and he 
gets exactly the files he needs to use that library. Naturally each 
configuration for a library needs to be well documented as to its 
meaning. This would also include instructions on how to use a particular 
configuration. A configuration could include all sorts of  things in the 
instructions to using it such as 'include these header files', 'define 
this macro', etc. etc. The idea is to be as friendly to the end-user a 
possible when the end-user just has a particular usage of a Boost library.

For many libraries there may just be one 'main' configuration but I see 
nothing wrong with the library programmer creating as many separate 
configurations as he likes. For instance if library X uses library Y 
only in its tests, it may create a 'testless' configuration so that 
library Y does not need to be part of the working set of library X if 
the end-user decides he does not need to run library X's tests just to 
use library X.

We would of course need some sort of tool, whether command-line like 
bcp, or GUI, where an end-user could pick the individual Boost libraries 
he wants, with the configuration he wants for each library, and he gets 
to then download the files he wants put into a working set he can use.

I realize that this is all very general and there is an enormous number 
of details to work out, but I think that if Boost does proceed along the 
path of individual Boost library distribution as opposed to monolithic 
distribution sometime in the future then something along the lines I 
have suggested would be a good idea.