Fundamentally, on the higher-level concepts, we may have to just disagree here. I find great value in explicitly specified dependencies (note I'm not talking about specifying every source file, but about specifying the relationship between libraries) as it makes the actual maintenance of the libraries and dependencies easier. I have sensed a growing appreciation and desire for this in LLVM, perhaps due to the latent layering problems that have gone unnoticed because the automatic system made things "just work".<br>
<br><div class="gmail_quote">On Mon, Jul 25, 2011 at 7:55 PM, Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es">ofv@wanadoo.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":idl">Taking time on writing contracts is good if and only if they<br>
are enforced. In practice, you can state a set of build dependencies<br>
that omits certain edges and lists unnecessary edges and the build will<br>
work on some circunstances, and fail on another ones (usually those that<br>
you didn't tested.)</div></blockquote></div><br><div>I don't disagree with this however, I just take a different approach: lets make the contract *and* enforce it. I have the good (or mis-)fortune of working with a build system that does a very careful job of enforcing and checking dependencies and layering violations. I regularly compare the CMake build with it to try to keep everything as close to accurate as possible. I'm hoping to be able to automate that  process some as the layering violations currently present get cleaned up, but all evidence is that *more* visibility and *more* explicitness will be what is required to get there.</div>