head aches in parser/Parser.hs

[Claus Reinke]

>>> It is confusing, though, that Cabal silently uses compiler/parser/Parser.hs,
>>> if it is meant to generate and use compiler/dist-stage[12]/Parser.hs.
>>>
>>> There should be a Cabal warning:
>>> "variant of generated file in source dir, using that instead of generated file".
>>
>> As far as I know, if you've got compiler/parser/Parser.hs
>> and compiler/parser/Parser.y then Cabal ignores the .hs one and
>> pre-processes the .y one into dist/ and uses the .hs from dist.
>>
>> If you're finding the opposite it's a bug and we need it reported with
>> enough details to reproduce.

to reproduce:

- take a recent GHC HEAD repo
- make distclean
- put a fake and clearly buggy parser/Parser.hs in compiler/
- for good measure, touch parser/Parser.y.pp (old make would
    have picked up on that clue)
- sh boot; ./configure ...; make

If I do that, I get an error in 'parser/Parser.hs' (note the location!).

The whole thing doesn't seem to be driven directly by Cabal, but
via a Makefile-stage1 generated by Cabal (make log attached).

Of course, it might be that Cabal doesn't realise that this is a bogus
file, and just tries to process it because it is there? The generated
makefile doesn't seem to have a way of recognizing 'parser/Parser.hs'
as unusual.

As I said, it would be nice to have a warning if there is a file in the
source dir that could be generated from another file in the source
dir (but where the generated version should be in another place),
and the build process should say in that warning whether it uses
or ignores such files.

There is also a line that seems to generate 'parser/Parser.y' in the
"wrong" location:

c:/mingw/bin/gcc -E  -undef -traditional -P -I../includes
    -x c parser/Parser.y.pp | grep -v '^#pragma GCC' > parser/Parser.y

That is the only reference to 'Parser.y' in the make log.

Hth,
Claus

> I'm actually happy that I'm no longer reproducing that,-) and don't
> have the old build log anymore, either. But from the two emails that
> started this thread, you can see that something else seems to be
> happening:
>
> http://www.haskell.org/pipermail/cvs-ghc/2008-August/043983.html
>
> In particular, after bringing the head up to date, make reported
> an error in 'parser/Parser.hs' !(the wrong generated file, in the wrong
> place, apparently left over and out of sync with 'parser/Parser.y'
> (itself generated and hence presumably also in the wrong place?)
> which in turn was in sync with 'parser/Parser.y.pp' (the real,
> original source).
>
> Then, only after a new distclean (this one managing to remove
> 'parser/Parser.hs'), the next error originated in the correct location,
> 'dist-stage1/build/Parser.hs', but was apparently due to the
> existence of a 'parser/Lexer.hs' (in the wrong location and out of
> sync with 'parser/Lexer.x'). I didn't actually check whether there
> was another generated 'Lexer.hs' somewhere, but simply removing
> that 'parser/Lexer.hs' and restarting the build removed the error.
>
> Perhaps you are thinking of what Cabal is going to do when
> dependency chasing is complete, or perhaps remainders of
> the old build system are interfering with Cabal, but it certainly
> looked as if a .hs file in the source dir was preferred over
> generating a new one from either .y or .x.
>
> Claus
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log.gz
Type: application/x-gzip
Size: 28457 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20080805/47194f6a/make.log-0001.bin