[Haskell-cafe] hat support in Cabal (was: How to debug GHC)

Malcolm Wallace writes:

Isaac Jones writes:

...

...

...

1. Hat requires users to restrict themselves to a certain small subset of the standard libraries, and to use hmake

Also the issue of how libraries are distributed in Haskell is a little bit in flux at the moment, since Cabal is still being polished.

This doesn't really have anything to do with Cabal as far as I know. Hat comes with pre-translated libraries for a subset of the GHC libraries. It's true that the libraries that come with the compilers may change in the future, partly due to Cabal, but I don't think this is the reason that Hat doesn't come with all the libraries. Hat doesn't even use Cabal, AFAIK, but hmake.

Well, the hope is that, eventually, Hat should be able to take any Cabal-ised library and transparently build it for tracing. Or maybe it will be Cabal that will support building for tracing as one "way" amongst others (profiling, etc). In any case, the point is that Hat pre-dates Cabal and so has no support for it, that Cabal is still under development, and that eventually there should be a good story for using Cabal+Hat together, but it isn't there right now.

I think the later is the way to go, add a "way" to cabal to build hat-enabled libraries. Cabal has all the information, the list of source files, extensions, which compiler you're building for (does that matter to hat?). This would be a great feature to add to Cabal :) But we don't really yet have a way to build a set of libraries in a particular "way". It's _less_ painful now to build profiling libraries, but you still have to go through and build each one. Maybe cabal-get can help with that. One problem for GHC is that ghc-pkg doesn't have any sense of "way" afaik... if I build package A without profiling support, and package B depends on package A, cabal's configure stage for package B can't detect whether or not A is built with profiling support... well, maybe it could go look for the profiling libraries or something. We might have a similar problem w/ hat-enabled libraries, and maybe slightly worse... I know that GHC profiling libraries can live alongside non-profiling versions; if you build package B with profiling, GHC just looks for the right version of package A's library in a standard place. But for Hat, I'd guess we want to keep a separate hierarchy for Hat-enabled libraries, maybe even a different package database (hmmm!). In fact, that's probably what should happen for profiling and any other "way" which requires that all packages be built the same "way". peace, isaac