Jhc does not need to do anything to support cabal, cabal is what would
need to support jhc. jhc already exports all the functionality needed
for cabal to interface with it if wanted.
That said, it wouldn't help a lot. Cabal is pretty poorly designed, it
has trouble keeping up with compatibility between different versions
of ghc, let alone different compilers. All of the cabal dependecies
are in terms of specific version numbers of ghc libraries (!!) rather
than actual feature tests meaning unless you had a database of ghc ->
jhc mappings that was continually maintained, or convinced every
person to continually test against every compiler, things won't work.
I moved to YAML because trying to parse cabal files was always just a
hack, it wasn't real support for cabal files because that can't easily
be done, it just confused things to try so didn't and went with a
standard format at the same time.
John
On Sat, Mar 16, 2013 at 11:34 AM, Kiwamu Okabe
Hi Brandon.
On Sun, Mar 17, 2013 at 3:11 AM, Brandon Allbery
wrote: Arguably its the other way around, as you found in the Cabal source: jhc can use whatever it wants, while it would be nice if Cabal (and hence cabal-install) supported jhc.
Whether jhc uses Cabal internally is not relevant to whether cabal supports jhc: for example, cabal supports Hugs, which does not itself support (and can't support, given how it works) cabal.
I don't understand Cabal completely. Cabal library is compiled by jhc or GHC? And jhc does not have database such as ghc-pkg. Is it easy to support Cabal without upstream developing power?
Now we have yaml format. And jhc use it. It's true.
Best regards, -- Kiwamu Okabe
_______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc