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