Ticket #50 (new enhancement)

Opened 3 years ago

Last modified 10 months ago

create compiler frameworks for new compilers

Reported by: ijones Assigned to:
Priority: normal Milestone: Cabal-2.0
Component: Cabal library Version:
Severity: normal Keywords:
Cc: Difficulty: very hard (<1 week)
GHC Version: 6.2.2 Platform:

Description

Email from John Meacham below. Another possibility is to make it rather like a hook.

I'd rather work on making a general compiler framework for it so that jhc can just drop a file describing its interface in /usr/share/lib/cabal/compilers/jhc.cabal-compiler or something and cabal will automatically be able to use it. Ideally, one would not have to upgrade their cabal just because they install (or write) a new haskell compiler. I think all compilers conform to one of

hmake-like: ghc --make, jhc, nhc + hmake interpreter-like: hugs gcc-like: ghc, nhc98

so a compiler declaration file would not have to be much more complicated than a string telling it how to invoke the compiler and a mapping of various extensions/cabal options -> compiler flags.

I'd also like to do something like this for preprocessors, which would be a much simpler project so will probably do first.

Change History

01/21/08 10:06:56 changed by duncan

  • difficulty changed from very hard to project(> week).
  • ghcversion set to 6.2.2.
  • platform changed.

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.

01/24/08 07:54:34 changed by duncan

  • difficulty changed from project(> week) to very hard (<1 week).
  • milestone set to Cabal-2.0.