package name mismatch

[Simon Marlow]

> It must have been only a warning in 5.02.3, or I could never have
> compiled it there.  (Before 5.02.3 we didn't use the package
> system like this at all.)
>=20
> Actually I would like this message to go away altogether in this case,
> if possible.  The actual situation is that GetPut.hs is in fact part
> of the package "uni-events-test", and the compiler is told to load
> uni-events-test on the command line.  However GetPut.hs is *also* in
> the current directory during this compilation, so GHC loads=20
> it from there=20
> instead.   I'm not sure what logic would be best here, but my=20
> suggestion=20
> would be that where a .hi file is found in an import declaration and
> has an unexpected package name, GHC keeps on searching.  If it finds
> a .hi file with a matching package name, it accepts it, otherwise
> accept the .hi file with the wrong package name and issue a warning.
>=20
> If that's too complicated, just ignore .hi files with the=20
> wrong package name.  But then people might complain . . .

I think this is all way too complicated.  GHC's view of modules is
fairly simple: they either reside in the home package or another
package.  If a module occurs in both, then previously it was an error,
now it is just a warning.  If we were using packages for dynamic
libraries, one of the reasons we originally added packages, then it
really *would* be an error and you'd be in trouble if you did this!

Can't you just fix your build so that the situation doesn't occur?

Cheers,
	Simon