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 wrote:

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

On Sat, Mar 16, 2013 at 11:34 AM, Kiwamu Okabe wrote:

Is it easy to support Cabal without upstream developing power?

No. This is my major issue with how cabal is designed. it is very tied to ghc and a 'closed-world' viewpoint where everything fits into its way of doing things. I really really want to design something better at some point. perhaps after another jhc release I'll spec something out (that would not be jhc specific). That said, it wouldn't be impossible to create a heuristic utility to try to compile cabal programs under jhc. I wouldn't want it something built into jhc but it could be something distributed with it. John

Hi Henning and others. On Mon, Mar 18, 2013 at 2:08 AM, Henning Thielemann wrote:

I have once updated JHC support in Cabal because I did not like to install a lot of packages manually. Cabal-install can install a lot of packages in one go. But actually I had to edit all involved Cabal files.

I have thought about Cabal and jhc many time. Then I decide to split the problem to two stage. Stage1. * Ajhc is installed with cabal. (Perhaps, also jhc.) * Ajhc's packages (hl files) is installed with jhc's YAML files. Stage2. * Ajhc's package (hl file) is installed with cabal. Now I am trying to build stage1. But stage2 is not needed for my usage. I will create thin wrapper installer for YAML files. Anyone try to build stage2? Best regards, -- Kiwamu Okabe