Yes, the module overlap restriction has started to bite us. It now
turns out that you can't build GHC from CVS if you have wxHaskell
installed.
Why? Because wxHaskell depends on some older non-hierarchical packages
(util in particular, which itself depends on lang). These package
populate the top-level module namespace, and steal a bunch of module
names that you might want to use in your program. In fact, GHC itself
contains a module with the same name as one in the lang package:
Generics. The error is real - if we *had* imported something from
wxHaskell, then the program would contain two modules called Generics,
and since the linker's name space is global, mayhem would ensue.
Because we're doing separate compilation, GHC can't tell that we haven't
actually imported anything from wxHaskell, so it has to be conservative
and assume that we will.
New GHCs are a bit stricter about complaining about duplicate modules,
with the result that GHC fails to build.
We know the reasons for this - they were all discussed at length in a
recent thread. What can we do?
1. Package builders should be careful about dependencies. Don't
depend on any non-hierarchical packages from an exposed package.
Daan - can you fix wxHaskell?
2. The GHC build could start using -fignore-all-packages to insulate
itself from the environment (or, simpler but more hacky:
-ignore-package lang). This isn't a *solution* as such, because
the problem affects everyone, not just us.
3. We could put some safeguards in place to avoid this happening
in the future, e.g. warnings from Cabal and/or ghc-pkg.
4. Cabal needs to start using -fignore-all-packages. Isaac?
Thoughts?
Cheers,
Simon