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.
b) If we assign libraries to one of the following levels, we might be
able to keep things under control (of course there'd be a couple more
than 5).
level 0: no libraries
level 1: stl libraries
level 2: config, exception ... // used indirectly by almost
everything
level 3: mpl, type_traits, ... // used by programs which use
generic programming
level 4: shared_ptr, .... // core utilities used by
other libraries
level 5: asio, serialization, date_time // used by applications rather
than by other libraries
there are no level 0 libraries
each level depends only on other libraries at a lower level.
This is mostly a convention so that when we add a library, we consciously
are
deciding where it sits in the dependency hierarchy rather than just letting
the chips fall where they may as we do now.
c) Consider refining a couple of major offenders - e.g. xml_archives so that
they would be separate dlls/libraries in the same module that they are now.
There is precedent for this. The serialization library module actually
creates two
libraries - serialization.dll and wserialization.dll . Bjam build scripts
could be
tweaked to produce in addition to these - xmlserialization.dll and
w_xmlserialization.dll.
Note that BCP would have to be tweaked to parse either the bjam or
some other spec file so follow just the dependencies relevant to the root.
We would then have an mechanism such that given an application like
my_app.cpp
#include