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 database.
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 -- John Meacham - ⑆repetae.net⑆john⑈