ghc-cvs-snapshot with wxHaskell
mai99dnn at studserv.uni-leipzig.de
Tue Feb 15 08:05:20 EST 2005
thank you for having a look at this. I will test it and I hope can compile
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??
On Tuesday 15 February 2005 12:25, Simon Marlow wrote:
> Thanks this looks like a bug that was introduced recently. Now fixed.
> 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.
More information about the Glasgow-haskell-users