Re: head aches in parser/Parser.hs

On Tue, 2008-08-05 at 14:51 +1000, Roman Leshchinskiy wrote:
On 05/08/2008, at 14:15, Judah Jacobson wrote:
It seems that the old, pre-Cabal build system did not clean some or all of the preprocessed files (such as Parser.hs). This was not much of a problem in practice, because the Makefiles used the relative timestamps to tell whether to regenerate Parser.hs from Parser.y. In contrast, Cabal stores all generated files in a separate directory (compiler/dist-stage[1/2]), and thus doesn't need to look at relative timestamps; so it gets confused by the old, leftover Parser.hs et al.
Ah, thanks for clarifying this. I did remove all the files by hand eventually but couldn't figure out why this was necessary.
Ironically this is another reason that switching to Cabal is a win -- cleaning of preprocessed files happens automatically.
Can't resist the urge to nitpick... IIUC, where the make-based system would generate Parser.hs at most once per build Cabal now (unnecessarily) regenerates it for each stage. So it is really using a different algorithm with slightly worse performance but better cleaning behaviour. It would have been trivial to implement with make, too.
But this has highlighted what is IMO a problem in Cabal's design. It doesn't know that to generate the module Parser it needs to start with Parser.y and just uses whatever source file it finds.
It knows it needs to find a source file for the module Parser, so it looks for the ultimate source file that could generate it, which is the .y file. If there is any .hs file too then it's ignored (though arguably we should warn if we find a .hs file too).
If that happens to be Parser.y things work but if it finds something else things break.
It knows that .y can be pre-processed to .hs so if it finds both .hs and .y then it knows that .y is the ultimate source file and pre-processes that. Do you think this is the wrong behaviour or are you observing different behaviour?
This looks very fragile to me. Could Cabal perhaps allow .cabal files to explicitly specify which source files to use? As in:
exposed-modules: Parser(Parser.y)
I don't think that's necessary. We can find the correct source file without hints. Though as I mentioned, it's arguable that we should warn if there is any potential ambiguity or search path shadowing. Duncan
participants (1)
-
Duncan Coutts