RE: search path wierdness

On 10 January 2005 14:40, Malcolm Wallace wrote:

> "Simon Marlow" <simonmar@xxxxxxxxxxxxx> writes:
> 
>>> Now presumably the gtk/Graphics/UI/Gtk/General/Signals.hi file
>>> remembers the module name. So ghc reads the module name from
>>> gtk/Graphics/UI/Gtk/General/Signals.hi and then for some reason
>>> looks for Signal.hi which of course it cannot find.
>> 
>> I don't quite follow.  When compiling
>> gtk/Graphics/UI/Gtk/General/Signals.hs did you specify -ohi
>> gtk/Graphics/UI/Gtk/General/Signals.hi?
> 
> I think the problem is probably slightly more convoluted.  When one
> module M exports entities from another N, ghc does not copy the
> relevant entities into the interface file for M, but rather plants
> a pointer to the interface for N, yes?

Yes!

> So I think probably a module like Graphics.UI.Gtk.Foo is importing
> and re-exporting from Graphics.UI.Gtk.Signals. Because, and only
> because, the file Signals.hi is in the directory Graphics/UI/Gtk,
> the import works.

Aha!  I see now.  GHC 6.4 has an improvement here:

$ cat >A.hs
module B where
$ cat >C.hs
import A      
$ ghc -c A.hs
$ ghc -c C.hs

C.hs:1:0:
    Failed to load interface for `A':
        Interface file "./A.hi"
        contains module `B',
        but we were expecting module `A'
        Probable cause: the source code which generated
          "./A.hi"
        has an incompatible module name

Duncan, I think that should address your problem, right?

Cheers,
        Simon