brainstorming ways to stabalize Cabal interface?

[John Meacham]

On Thu, Jan 19, 2006 at 01:59:01PM -0800, Isaac Jones wrote:
> But if I agree to this, you have to get it going for JHC ;)

certainly, although, rather than make jhc another special case in cabal,
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.


incidentally, could we get cabal to ignore any field starting with 'x-'
as a user defined extension?

I'd like to use locally things like

x-publish-site: /home/john/public_html/...
x-darcs-repo: http://repetae.net/repos/jhc

or experimental things like
x-jhc-namespace: 0x220 

without cabal getting huffy about unknown fields.

obviously any popular and generally useful ones would eventually be
standardized and the x- can be discarded.

this is a fairly standard convention among file formats and is used in
mime types too.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈