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 <boost/date_time.hpp> #include <boost/date_time/serialization.hpp> #include <boost/archive/text_iarchive.hpp> ... int main(){ .... } we could invoke BCP BCP my_app.cpp which would produce output module library header files date_time date_time.dll .... serialization serialization.dll ... So the user would know which modules he would have to include to build his app. Disadvantages not totally automatic - I don't believe that's possible now not perfect - might specify some unnecessary dependencies Advantages actually doable relatively modest changes in BCP perhaps a hand prepared file for some modules perhaps some minor re-factoring for output from some libraries - e.g. serialization would pretty much work - would be flexible provide user with smaller requirements for smaller applications permit (by making all the *.cpp files in a library) creating of larger dependency list when required when it didn't work at least we wouldn't have a huge system to try to tweak and debug we could work around it by tweaking the hand prepared helper So that's the best I can come up with. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-dependency-reports-s-... Sent from the Boost - Dev mailing list archive at Nabble.com.