ghc-cvs-snapshot with wxHaskell
mai99dnn at studserv.uni-leipzig.de
Tue Feb 8 06:42:57 EST 2005
> Could you tell us what command line was supposed to generate the
> Map.d.in or Map.d file? It may be a bug, there were a few changes in
> the driver recently.
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)).d.in &&
sed -e 's|$(basename $(2))|$(basename $(1))|' -e
's|\.hi|\.o|g' $(basename $
(1)).d.in > $(basename $(1)).d && \
$(call silent-remove-file,$(basename $(1)).d.in)
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/Map.d.in 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/Map.d.in: 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 Map.d.in file somewhere around (maybe Map.hs.d.in ?) I guess it
> > is still in the source directory instead of the out/... directory.
More information about the Glasgow-haskell-users