Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-07 15:12:03

At 11:46 AM 8/7/2002, Douglas Gregor wrote:

>My first thought was to use graphviz to create a header dependency DAG.
>Unfortunately, this approach results in big graphs, and we really can't
>putting the headers for every dependency in each graph. Here's the
>graph for boost/function.hpp:

At least it was entertaining to look at!

>My second attempt was to use a JavaScript tree component to let the user
>interactively explore dependencies. Click on the '+' near any top-level
>header to see the subheaders, etc. Unfortunately, browsers don't like to
>handle this really large trees and tend to be very, very slow about it.
>Perhaps we could do this but at the library level? e.g., each library
>have a 'depend.html' that lets you explore the dependencies starting at
>library's user-level headers. Then the tree would work well. Here's a
>slow tree for all top-level headers (with thanks to Morten for the
>of course):

I've only got a 64KB ISDN line here, so got bored and gave up waiting for
that one to download.

>Just for completeness, I generated the dependency table in the same style
>the current table. It uses some heuristics to try to figure out what is a

>user-level header and what isn't (so we don't need to maintain a
>header" list by hand), and tries not to repeat information within the
>dependencies for a header. It's still big, though, because Boost is big:

I gave up on that one too, but got enough to display a partial table.

In looking at counting_itererator.hpp, it occurred to me that once we know
a header uses boost/config.hpp, we know it is dependent on the config
library, and don't have to report each and every config library header.
Likewise, once we've reported counting_itererator.hpp depends on
type_traits, we don't have to report the name of every
boost/type_traits/... header.

It probably isn't all that useful to know that a library uses various C++
standard library headers either. That might be another area to prune.

And of course we already know that a library is dependent on its own
headers, although it isn't always easy to know what "its own" headers are
if they aren't in a sub-directory. Another reason to structure directories
as the most recent boost libs have done.

In other words, the granularity desired "depends on" column is really at
the library than at the header level.

Does that make sense?

>The Perl code used to generate the dependency information follows. The
>to actually generate each of the formats is beyond trivial, but I can
>post/commit it if anyone is interested.

I've got boost scripts written in Perl, Python, bash, Windows .bat, and
C++. Some will run only under the Windows command line interpreter, a few
only under bash. It's a mess. I'm trying to move all the non-trivial
stuff to C++. If C++ doesn't have a needed facility, I'm trying to add
library support for it. With little C++ script-like programs, I can deal
with problems directly or get help from any other Booster. So please don't
think I ungrateful for a Perl script; I'm just moving in another direction.



Boost list run by bdawes at, gregod at, cpdaniel at, john at