On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel wrote:

Btw, I simply prepend to the $PATH env variable, or pass the appropriate executable name to `cabal`'s

-w --with-compiler=PATH give the path to a particular compiler

I don't understand, aren't they all in /usr/local/bin? Or do you use a version-specific prefix when installing each ghc version? Also, ghc is not just the compiler, but also hsc2hs hpc runghc ghci ghc-pkg haddock-ghc. At the least, ghc-pkg has to be the right version, but all of those are version specific since they'll break if you remove their /usr/lib/ghc-version.

On Fri, Jul 31, 2015 at 11:42 AM, Herbert Valerio Riedel wrote:

Sorry, I assumed this w/o saying;

I maintain and use myself

https://github.com/hvr/multi-ghc-travis

Ah, I see. I agree your approach is more principled in that it's local rather than modifying global state. In practice, though, my way of relinking the symlinks is simple and has worked well enough for my modest needs. And for me, the global modification is actually what I want. But it also sounds like this is also demonstrating the "everyone creates their own solution" that I was suggesting might be happening. I didn't know about the cabal cleverness, but it wouldn't be that useful for me since I don't use cabal. While cabal is useful, I don't think we should delegate low level functionality to it such that you can't use ghc without also committing to its not-a-build-system build system. Given that modifying global /usr/local state is the way that ghc installation (along with unix installation in general) works, wouldn't it still make sense to be more consistent about the binary names to make switching versions or uninstalling less error-prone? As far as shipping with scripts for versioning and uninstallation, I still think it makes sense to have a simple built-in way. I know I've seen a few versions of the library uninstall script floating around, so I can't be the only one. I seem to recall the OS X platform install had some uninstall or version switching scripts, but specialized to the OS X directory layout. Switching to a more principled scheme where you have truly local versions sounds like a much more ambitious task... eventually winding up with nix and plan9 style local mounts... or something. It's a worthy goal but more difficult than renaming a few binaries.

[...] The only thing I find missing is the ability to install a binary distribution without overwriting the existing symlinks (e.g. ghc -> ghc-7.8.4).

I second the OP's request and Reid's one: I think the binary distributions for *nices should neither contain unversioned executables nor should they try to link these to the versioned ones for themselves. This is exactly what update-alternatives is for, and it does it in a very principled, standard way everyone understands (or can at least look up :-). Death to the not-invented-here syndrome! :-D

On Sat, Aug 01, 2015 at 06:31:38AM +1000, Erik de Castro Lopo wrote:

I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have:

* ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/

To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC.

I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. It would be nice if cabal-install had an installation-time option to set its prefix directory FOR EVERYTHING. The best cludge I found was scripts /usr/lib/ghc-*/bin/mycabal that call /usr/lib/ghc-*/bin/cabal with appropriate options... Wolfram

On Fri, Jul 31, 2015 at 10:31 PM Erik de Castro Lopo wrote:

I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have:

* ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/

To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC.

I actually have a shell function to to do this PATH mangling. I can document this more fully if anyone is interested.

I have a similar setup where I install different versions of GHC in different directories. But I use GNU stow[1] to create and remove symlinks in /usr/local/* so that I can use one version of GHC as the default. [1] https://www.gnu.org/software/stow/ Josef

On Mon, Aug 3, 2015 at 10:04 AM, Alexander Berntsen wrote:

On 31/07/15 20:10, Evan Laforge wrote:

...

Come to think of it, shouldn't ghc include this, instead of everyone creating their own shell scripts by hand? I don't think so. This is usually done in the userland -- at least in GNU+Linux distributions.

More to the point, various distribution methods already include such things (e.g. NixOS, Debian's alternatives system, MacPorts' "port select") plus there are various mechanisms for implementing this on an ad-hoc basis (GNU stow, environment modules, etc.). Downstream packages implementing their own versions of this except speicifically on an opt-in basis (e.g. configure option) tend to interfere with these and complicate inclusion into existing package systems. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net