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

Isaac Jones ijones at syntaxpolice.org
Mon Sep 5 15:28:32 EDT 2005

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:

> Isaac Jones <ijones at syntaxpolice.org> 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

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



More information about the Haskell-Cafe mailing list