Thanks this looks like a bug that was introduced recently. Now fixed. Cheers, Simon
On 08 February 2005 11:43, Patrick Scheibe wrote: > Hi, > >> >> 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. >> >> 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 check. > > 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: > > <comment> > # 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: > # "http://make.paulandlesley.org/autodep.html" > # > # (Unfortunately, there are situations where this method doesn't work > for Haskell > # modules -- but these situations are exteremely rare in practice, > nothing that > # 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: > # "http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html" > # (We might use include files in the future to split this file in > smaller chunks.) > # > # 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 implicit > # rule for interface files ("%.hi: %.o"). > </comment> > > I sent a copy to Daan and hope he joins the discussion and/or it him > fixing the problem without much expenditure of time. > > Cheers > Patrick > > >> 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. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users