#50: create compiler frameworks for new compilers ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.2.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: very hard => project(> week) * ghcversion: => 6.2.2 * platform: => Comment: The `Compiler` abstraction should certainly be beefed up. I'm not sure we need to go as far as making a external serialised form. Currently the `Compiler` value is passed around but is used as a bit of dumb data when it should really carry methods for doing interesting things and we should not be switching on the `CompilerFlavour`. The difficulty with doing this is that currently the `Compiler` value is passed around using the `LocalBuildInfo` which implements Show. We should really pass `Compiler` as a parameter but we cannot do that without changing the type signatures of the `UserHooks` which would break all custom `Setup` script again. So we have to synchronise this change with our next planned break of `UserHooks`. Ideally that break should include a plan for an api style that does not involve so many breaks when we want to pass just a bit more info, like using some kind of monad where we can extend the environment without breaking existing code. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/50#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects