Boost logo

Boost :

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):
> >
> 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

> 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):

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


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