head aches in parser/Parser.hs
claus.reinke at talk21.com
Tue Aug 5 10:17:33 EDT 2008
>> It is confusing, though, that Cabal silently uses compiler/parser/Parser.hs,
>> if it is meant to generate and use compiler/dist-stage/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.
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
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,
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.
More information about the Cvs-ghc