Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-01 08:34:53

Peter Dimov wrote:

> Nat Goodspeed wrote:
> 
> 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. 

I don't think the dependencies need to be listed manually *necessarily*, even 
initially, because Stephen Kelly also generated his (module-level) dependency 
graphs automatically if I'm right. It is true that I didn't rule out the possibility, 
however. You raise a valid concern.

Testing whether all necessary dependencies are included was part of my plan, 
but I didn't mention it yet because I considered it a detail that could be covered 
after we agree that modularization should be finished.

-Julian