Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create compiler frameworks for new compilers #57

Closed
bos opened this issue May 24, 2012 · 2 comments
Closed

create compiler frameworks for new compilers #57

bos opened this issue May 24, 2012 · 2 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #50, reported by @SyntaxPolice on 2006-01-20)

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.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2006-01-20)

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.

@jsl
Copy link

jsl commented Feb 24, 2015

Doesn't seem like there is activity on this since 2006. I propose closing, please re-open a new issue if this is still desired.

@tibbe tibbe closed this as completed Feb 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants