Hi Simon, thank you for having a look at this. I will test it and I hope can compile wxHaskell tonight. Where is the fixed version of the ghc? Is it one of the stable night releases or should I make a update of the developer cvs tree of ghc?? Cheers Patrick On Tuesday 15 February 2005 12:25, Simon Marlow wrote:
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.