Re: [boost] Header dependency table

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-07 16:51:10

On Wednesday 07 August 2002 04:12 pm, Beman Dawes wrote:
>  >slow tree for all top-level headers (with thanks to Morten for the
>  >component,
>  >of course):
>  >  http://www.cs.rpi.edu/~gregod/hdr_depend/index.html
>
> I've only got a 64KB ISDN line here, so got bored and gave up waiting for
> that one to download.

I've managed to shrink the file size down to something more reasonable (< 
200KB). If you're still interested in checking it out, it's at the same 
place:
  http://www.cs.rpi.edu/~gregod/hdr_depend/index.html

> 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.

That depends... do you want to skip around the dependency file to see the 
underlying dependencies for every header? That seems a bit tedious. However, 
I understand your point, and tried to cut out some redundant information 
without making the user zip around a large file. Here's the complete header 
dependency tree for boost/function.hpp (< 30KB):
  http://www.cs.rpi.edu/~gregod/hdr_depend.html

Every header #included is there, but the children of each header are only 
expanded once. For instance, the first #include of 
boost/function/function_template.hpp brings in a huge number of other headers 
(all of type_traits, all of preprocessor, all of config). Later references to 
function_template.hpp won't include these other libraries.

> 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.

The standard headers won't have an information of what they include, so they 
take up very little space when compared to, e.g., the preprocessor or type 
traits libraries.

> 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.

That could be another way to compress the dependency lists, sure.

> In other words, the granularity desired "depends on" column is really at
> the library than at the header level.
>
> Does that make sense?

Yeah, but it's a maintenance nightmare. Then every header has to be associated 
with a library somehow. We can use the directory naming scheme to some 
extent, but I wonder how far that will go...

        Doug