On Fri, Jul 31, 2015 at 11:42 AM, Herbert Valerio Riedel <hvrie...@gmail.com> 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. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users