Boost logo

Boost :

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.

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