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 [email protected]http://www.haskell.org/mailman/listinfo/cvs-ghc
make.log.gz
Description: GNU Zip compressed data
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
