[Hackage] #50: create compiler frameworks for new compilers

[Hackage]

#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