Boost logo

Boost :

Subject: Re: [boost] [modularization] Extract xml_archive from serialization
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-09-17 15:26:35

Peter Dimov-2 wrote
> Robert Ramey wrote:
>> The definition of "module dependency" is unclear to me.
> The definition of module dependency that the report uses is:
> module X depends on module Y if some header of X's includes some header
> of
> Y's
> where "some header of X's" refers to the headers in libs/X/include.
> That is, it doesn't track dependencies from libs/X/src or libs/X/test.
> In other words, if someone tries to *use* X by including some of its
> headers, he needs (in the general case) to also have Y's headers
> installed,
> or the code will not compile.

OK -

but what is the first code node? Is the users application? Is one of the
tests? Is it all the cpp files in the library X?

I think my biggest problem is the word "module". if I break date-time into
two dlls - date_core and date_time_serialization will the "module" be one
or the other or both? If date-time has a bunch of headers like
etc. and one other library uses just that - is the whole other library
upon date-time? Does this change if one uses the popular "convenience

To me the "module" is sort of slippery and doesn't very well capture which
concerned about.

The attempt to say something which seems really natural like "library Y is
a pre-requisite for library X" is, I think, a big problem. I realize you've
it for purposes of running you dependency tool, but I don't think it's the
definitive answer (I don't think there is one). That's why the reliance on
tool is leading us to difficulties.

As I've said, this way of characterizing it doesn't help up in deciding what
the best thing to
do is.

Robert Ramey

View this message in context:
Sent from the Boost - Dev mailing list archive at

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