Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Peter Dimov (lists_at_[hidden])
Date: 2014-05-30 10:14:16

Nat Goodspeed wrote:
> I've been assuming that Julian's proposal will require, at least 
> initially, that someone (the library maintainer, an interested volunteer) 
> manually edit a specification in some syntax of the other libraries on 
> which this one directly depends. That information could be informed by, 
> but need not be identical to, the output of a tool.
>
> In that case, Glen's suggestion only requires that the specification 
> syntax include some way of annotating each dependency: "only for the 
> following toolsets..."

Ah. I misunderstood.

Manually specifying dependencies is probably better than nothing. It has two 
significant drawbacks though. First, it's easy to get them wrong. I've been 
surprised a number of times by boostdep.exe when it uncovered a dependency 
of which I wasn't aware.

Second, even if you get them right at first, it's easy for them to become 
wrong. Adding an #include to fix a bug is something that few of us think 
about twice. This will be especially relevant for libraries maintained by 
the CMT, although I don't intend to single these out; ordinary maintenance 
is bound to introduce dependencies by mistake for the same reason it's easy 
for humans to get dependencies wrong in the first place.

And even if the library is not touched at all, a header can migrate from 
module A (marked a dependency) to module B (not marked as such).

For these reasons, manual specification of dependencies can be reliable only 
if these specifications are tested as part of the regression tests. That is, 
if the tests for module X operate in an environment in which only the stated 
(and transitive) dependencies of X are present.