[nightly] 10-Aug-2008 build of HEAD on i386-unknown-linux(cam-02-unx.europe.corp.microsoft.com)

[Claus Reinke]

| I think we should not build the non-core libs with -Werror. It makes
| perfect sense for the core libs where the ghc team effectively maintains
| them, but not for non-core ones.

>But time *is* a core lib.  Similarly containers, pretty, filepath, directory...  The full list is 
>below.
>GHC is simply a client for these libraries.  Should they have -Werror or not? I'm not sure.

The first time I joined a project with rcs (and in those days, that
meant RCS), I was given a few firm rules, the most important of
which was (emphasis added):

    1. whatever I check in, the _whole_ thing has to build ok

An immediate corollary was:

    2. if _my_ changes break someone else's code, _I_ have to fix that

In these days of distributed rcs with one build using multiple repos
or even multiple rcss, those rules aren't as clear, but I'd suggest to
interpret GHC+corelibs as a unit, and to apply rules 1 and 2.

In fact, until the Haskell Platform is ready to take over from extralibs,
it would be helpful to apply the same rules to extralibs as well.

Otherwise, we'll end up here

? It highlights an important advantage of having a nontrivial set
? of extralibs in the ghc buildbot: early warnings about when and
? how ghc changes are going to break user-/library-code.
?
? Once the extralibs go, that feedback will be less immediate, the
? spread of breakage will be wider, and the current "why should
? Ghc Hq have to worry about network package maintenance?"
? could easily turn into a major source of friction, with both Ghc
? Hq and library maintainers insisting that the breakage isn't in their
? boat ("but HEAD fast builds just fine","but I didn't change a bit
? in my library code") and users likely to pay the price.

much faster than even I feared just a week ago..

Claus

ps. so that you don't have to iterate over failures:
http://www.haskell.org/pipermail/cvs-ghc/2008-August/044021.html