ghc-cvs-snapshot with wxHaskell

[Patrick Scheibe]

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.