Subject: Re: [boost] questions regarding dependency reports(s)
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-09-27 01:20:42
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
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
level 0: no libraries
level 1: stl libraries
level 2: config, exception ... // used indirectly by almost
level 3: mpl, type_traits, ... // used by programs which use
level 4: shared_ptr, .... // core utilities used by
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
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
libraries - serialization.dll and wserialization.dll . Bjam build scripts
tweaked to produce in addition to these - xmlserialization.dll and
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
we could invoke BCP
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
not totally automatic - I don't believe that's possible now
not perfect - might specify some unnecessary dependencies
relatively modest changes in BCP
perhaps a hand prepared file for some modules
perhaps some minor re-factoring for output from some libraries -
would pretty much work - would be flexible
provide user with smaller requirements for smaller
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.
-- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-dependency-reports-s-tp4667966p4667970.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk