simultaneous ghc versions

[Evan Laforge]

On Fri, Jul 31, 2015 at 11:42 AM, Herbert Valerio Riedel
<hvriedel at 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.