john at repetae.net
Tue Oct 16 21:19:51 EDT 2007
On Tue, Oct 16, 2007 at 10:46:26AM +0100, Duncan Coutts wrote:
> So what is the solution? We could take advantage of the fact that we
> know that hsc2hs really uses ghc as it's C compiler and change the flags
> we pass it when we happen to be building with ghc. On the other hand
> this all becomes non-portable. In fact this totally relies on a package
> database to remember what search directories to use when pre-processing
> dependent packages. In other words it only has a chance of working with
> ghc at the moment, or nhc in future if/when it implements a package
> What to do?
> Short and long term suggestions please.
This doesn't really solve the problem, but as a long term goal,
it would be nice if hsc2hs could be split off into its own project and
distributed independently of any compiler. so, like, people would have
haskell-utils: hsc2hs, cabal-install, runhaskell
ghc: ghc compiler
jhc: jhc compiler
all installed and non-conflicting as separate packages (in the sense of
OS software packages, not ghc ones) that don't conflict.
John Meacham - ⑆repetae.net⑆john⑈
More information about the Libraries