Malcolm Wallace <[EMAIL PROTECTED]> writes: > Isaac Jones <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
