You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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.
(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.
The text was updated successfully, but these errors were encountered: