ghc-cvs-snapshot with wxHaskell

Patrick Scheibe mai99dnn at
Tue Feb 8 06:42:57 EST 2005


> Could you tell us what command line was supposed to generate the
> or Map.d file?  It may be a bug, there were a few changes in
> the driver recently.
> Cheers,
> 	Simon

I hope I can help you. It would be better Daan would have a look, because it 
is his code and he knows exactly what he has done.

If I understand the things right, then the following call does the depency 

make-hs-deps    =$(HC) $(2) $(3) -M -optdep-f -optdep$(basename $(1)) && 
                 sed -e 's|$(basename $(2))|$(basename $(1))|' -e 
's|\.hi|\.o|g' $(basename $
(1)) > $(basename $(1)).d && \
                 $(call silent-remove-file,$(basename $(1))

I think the important thing you want to know is that ghc is called with the -M 
option!? Here is a comment I found in the Makefile. It is probably usefull:

# Dependencies are handled (almost) automatically: no need for "make depend" 
# Makefile implementation notes:
# The dependency (.d) files are generated together with object files using
# the compiler -M switch. Such dependency file is later processed
# by sed to prepend the proper directory to the target and to move it
# into the proper (imports) directory. The way dependency files are handled
# was 'discovered' by Tom Tromey, and described by Paul Smith,
# see "advanced auto-dependency generation" at:
# ""
# (Unfortunately, there are situations where this method doesn't work for 
#  modules -- but these situations are exteremely rare in practice, nothing 
#  can't be solved by a "make clean; make" command. I believe that in the end
#  this method is much more robust than "make depend".)
# We use a single makefile in order to correctly resolve dependencies
# between the different projects -- a recursive make fails to do that,
# see "recursive make considered harmfull" at:
# ""
# (We might use include files in the future to split this file in smaller 
# We don't use implicit rules (i.e. "%.o: %.c") as the VPATH mechanism can't
# deal with modules with the same name in different directories :-(
# We edit (sed) the haskell dependency files to change dependencies on .hi
# files to .o files. We just disregard .hi files and assume they are always
# generated together with the .o file. This allows us to leave out the 
# rule for interface files ("%.hi: %.o").

I sent a copy to Daan and hope he joins the discussion and/or it him fixing 
the problem without much expenditure of time.


> On 07 February 2005 19:28, Patrick Scheibe wrote:
> > It seems that there are changes in the OpenGl library during the last
> > month. So I decided to load a really young cvs version of the ghc
> > (ghc-6.5.20050206-src.tar.bz2). The compilation works fine.
> >
> > My Problem is, that I also need the wxHaskell library. This
> > compilation fails with the message:
> >
> > <wxoutput>
> > ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi
> > out/wxdirect/Map.hi -odir out/wxdirect/  -package parsec
> > -iout/wxdirect
> > sed: kann out/wxdirect/ nicht lesen: Datei oder Verzeichnis
> > nicht gefunden
> > make: *** [out/wxdirect/Map.o] Fehler 2
> > </wxoutput>
> >
> > The third line is german and means "sed: unable to read
> > out/wxdirect/ File not found".
> > This or an almost similar error appears when I use the cvs version of
> > wxhaskell.
> >
> > I'm also in contact with Daan Leijen, the main developer of wxHaskell.
> > He said:
> >
> > <daan>
> > Darn, it seems that ghc changed its  options or something. My makefile
> > generates dependency files (".d" files) using ghc. Since "sed" can't
> > find the file, it is either not generated or it is put at the wrong
> > directory. Can you look around in your file system if there is a Map.d
> > or file somewhere around (maybe ?) I guess it
> > is still in the source directory instead of the out/... directory.

More information about the Glasgow-haskell-users mailing list