patch applied (ghc): Use update-alternatives for handling generic tool names

[Sven Panne]

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 
distributions.

> 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'.

Cheers,
   S.