FWIW, I used to employ a combination of environment vars and registry entries (for file associations) on Windows in order to be able to work with multiple GHC versions.  The environment vars (e.g. for PATH or LIB inclusion) would all depend on a GHC_HOME var, which could be redefined to point to the GHC installation du jour.
<br><br>I am not sure how much common structure there would be among installations of GHC, NHC, HUGS, etc., but maybe the same thing could still work, possibly with some tweaks.<br><br><br>Cheers,<br><br>Dinko<br><br><br>
<div><span class="gmail_quote">On 3/15/07, <b class="gmail_sendername">Sven Panne</b> &lt;<a href="mailto:sven.panne@aedion.de">sven.panne@aedion.de</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 15 March 2007 10:56, Malcolm Wallace wrote:<br>&gt; [...] If you install hmake, and change &#39;runhaskell&#39; to runhs, it works.<br><br>This reminds me of something, at least for the Linux world: No Haskell
<br>compiler/interpreter should directly install &#39;runhaskell&#39;. Instead of that,<br>it should only directly install runghc, runhugs, runnhc, ... and use<br>update-alternatives (or a similar technology for that platform) to inform the
<br>native package system that there is a new alternative for &#39;runhaskell&#39;.<br>Similar reasoning holds for cpphs, hsc2hs and friends. I&#39;ll update the .spec<br>files accordingly soon.<br><br>Doing it that way, the local sysadmin has the choice to configure which
<br>Haskell implementation is the default and several versions of the same<br>implementation could be installed side by side.<br><br>I don&#39;t have a clue how to do this correctly for Mac OS X and Windows, though.<br>And &#39;runhs&#39; is actually not a very good name to run nhc98, runnhc or runnhc98
<br>would be much better IMHO.<br><br>Cheers,<br>&nbsp;&nbsp; S.<br></blockquote></div><br>