ghc-cvs-snapshot with wxHaskell

[Simon Marlow]

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.