On Mon, 2007-08-06 at 19:34 +1000, Manuel M T Chakravarty wrote:

...

...

../libraries/Cabal/Distribution/System.hs:14:10: Not in scope: `System.Info.os'

This is on MacOS compiling with GHC 6.6.1.

Duncan, did you run validate before pushing all these recent cabal patches?

No. I checked that it built on it's own and passed some of it's own regression tests.

...

We shouldn't expect Cabal developers to run GHC's validate when pushing patches. The right thing to do is for GHC to use a branch of Cabal (subset only, so no conflicts), and only push patches to GHC's branch after a validate.

This entails some extra overhead to the development model. Thoughts?

Depends on the Cabal developers, I guess. Making sure that GHC's build doesn't break might be a good regression test for Cabal. If they don't like that, using a subset-branch sounds fine (something like packages/Cabal-ghc).

Problem is, checking that Cabal builds fine is no guarantee that ghc builds with it. For example ghc uses lots of compat/Distribution/*.hs files (that merely #include some real Cabal/Distribution/*.hs files) and if we make slight module dep changes in Cabal it requires adding more such files. That was the source of one recent break, though not the System.Info.os one. So yes, we'd have to run the full ghc validate script. If possible I'd rather avoid making all Cabal contributers do that since we're trying to make Cabal development more assessable.

However, this raises the general question of GHC's core packages. Cabal might be a special case, but generally validate is only moderately useful (as we just saw) unless the obligation to run it applies to all core packages of GHC. (I don't think it makes sense to use subset-branches for all core packages.)

But even if we did run validate, sometimes we do have to make breaking changes to the Cabal interface. Especially in this development cycle we've been trying to get all the breaking changes through so we can I'm not sure it's ok to ask Cabal contributers to not only run validate after making api changes, but also to fix ghc and all core packages that break due to that. It's too heavy. IMHO, our main problem in Cabal is lack of development progress rather than too many changes too quickly. So what to do? One thing I suggested previously was a way of making temporary branches and feeding them to the build bots. So we could push these kinds of changes to such a branch and see what the fallout is without breaking the main tree. It'd need some automation to make it manageable I suspect. Perhaps it should be something where the core branch pulls upstream changes into the temp branch and runs them through the build bots, using the last buildable ghc, then if it builds it gets pulled through to the branches that ghc uses. So it'd still be automatic in the usual non-breaking case. In the breaking case we get an email and the changes do not propagate into the ghc head branches. Duncan