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.