head aches in parser/Parser.hs

[Roman Leshchinskiy]

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. If that happens  
to be Parser.y things work but if it finds something else things  
break. 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)

Roman