On 31/01/13 18:57, Ian Lynagh wrote:

On Thu, Jan 31, 2013 at 12:23:02PM -0000, GHC wrote:

...

I can't compile `DynFlags` on my 256MB Raspberry Pi. Could we do something about having less auto-generated code in this module please?

-- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7258#comment:13

The ticket's really about performance problems in the compiler rather than DynFlags in particular, so moving to the list.

Even the non-generated code in DynFlags is quite large, and ungainly to edit. What would you think about splitting it up, perhaps moving DumpFlag, GeneralFlag and WarningFlag into separate modules?

Ideally each module would also export a [Flag (CmdLineP DynFlags)], which would then be ++ed together in DynFlags, but I'm not sure if that's possible without making the modules mutually recursive. On the other hand, perhaps there's a way to split it up which would remove the need for (some of) the existing import loops; I'm not sure how feasible that is OTTOMH.

What about just moving PlatformConstants into a separate module? The deriving Read is the main problem - couldn't you generate a ReadP parser instead? Commenting out the deriving Read makes DynFlags compile twice as fast. It may be a GHC bug, but fixing that won't help us when bootstrapping with older compilers. Cheers, Simon