Re: [boost] questions regarding dependency reports(s)

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
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-tp4667966p4667970.html
Sent from the Boost - Dev mailing list archive at Nabble.com.