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.