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
gregorian.hpp
etc. and one other library uses just that - is the whole other library
dependent
upon date-time? Does this change if one uses the popular "convenience
header
date-time.hpp?

To me the "module" is sort of slippery and doesn't very well capture which
we're
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
answered
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
this
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: http://boost.2283326.n4.nabble.com/modularization-Extract-xml-archive-from-serialization-tp4667615p4667682.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk