patch applied (ghc): Use update-alternatives for handling
generic tool names
sven.panne at aedion.de
Fri Mar 16 07:18:21 EDT 2007
On Thursday 15 March 2007 21:34, Ian Lynagh wrote:
> hsc2hs gives different output on different platforms, so anyone building
> from source needs it, not just those building from darcs.
I came to the same conclusion this morning while standing under the
shower... :-) So things are quite different for hsc2hs than for alex and
happy. In the latter case we can require these tools for bleeding edge
developers and include pre-generated files in the released source
> Regardless, it would be good to merge whatever differences there are
> between ghc's hsc2hs and the standalone one and then have ghc grab the
> canonical hsc2hs with darcs-all.
That's exactly my plan.
> If you meant hsc2hs should be a dependency even for people building from
> a tarball, then that is Simon's call.
No, that would be bad. I think that the GHC project (and Hugs/nhc) should grab
the canonical hsc2hs and use it for its build process, ignoring any other
hsc2hs, even if it's already there. (Would there really be a noticeable
benefit autodetecting an already installed hsc2hs and use that instead?) But:
We *do not* install hsc2hs anymore, and make it a standalone project
distributed separately. Same for cpphs.
I think this disentangling of tools and compilers/interpreters makes sense,
and the update-alternatives technology is only needed for 'runhaskell'.
More information about the Cvs-ghc