simultaneous ghc versions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

simultaneous ghc versions

Evan Laforge
The recent release of ghc 7.10.2 reminded me of something I meant to
ask about a long time ago.  Most of the binaries ghc installs are
versioned (x linked to x-7.10.2), with some exceptions (hpc and
hsc2hs).  Shouldn't they all be versioned?  Also, 'haddock' is
inconsistent with all the rest, in that it's haddock linked to
haddock-ghc-7.10.2.

I've long used a few shell scripts (recently upgraded to python) to
manage ghc installs.  A 'set' which creates symlinks to make a
particular version current, and an 'rm' to remove all traces of a
version.  But due to the inconsistency, I have to remember to run
"fix" first, which moves the unversioned binaries to versioned names.

As an aside, I have three scripts I use all the time: set version,
remove version, and remove library.  Come to think of it, shouldn't
ghc include this, instead of everyone creating their own shell scripts
by hand?
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Herbert Valerio Riedel-3
On 2015-07-31 at 20:10:01 +0200, Evan Laforge wrote:

[...]

> I've long used a few shell scripts (recently upgraded to python) to
> manage ghc installs.  A 'set' which creates symlinks to make a
> particular version current, and an 'rm' to remove all traces of a
> version.  But due to the inconsistency, I have to remember to run
> "fix" first, which moves the unversioned binaries to versioned names.
>
> As an aside, I have three scripts I use all the time: set version,
> remove version, and remove library.  Come to think of it, shouldn't
> ghc include this, instead of everyone creating their own shell scripts
> by hand?

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

option. Having user-global symlinks seems to be the least desirable way
to handle multiple installed ghc versions to me, as the choice becomes
global (so you when you switch ghc versions in one xterm, this suddenly
affects all other xterms, rather than applying only for the scope of the
one single xterm where I want this to apply).
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Evan Laforge
On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel
<[hidden email]> 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.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Herbert Valerio Riedel-3
On 2015-07-31 at 20:32:43 +0200, Evan Laforge wrote:
> On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel
> <[hidden email]> 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?

Sorry, I assumed this w/o saying;

I maintain and use myself

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

which in fact uses version-specific install prefixes, resulting in the
`bin` folder being

 /opt/ghc/<version>/bin

> 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,

`cabal` is actually clever enough to locate the appropriate executable,
if I pass it a specific ghc executable (iirc it looks in the same folder
where `ghc` was found)

  $ which ghc-pkg
  /opt/ghc/7.10.2/bin/ghc-pkg
 
  $ which hsc2hs
  /opt/ghc/7.10.2/bin/hsc2hs
 
  $ cabal configure -w /opt/ghc/7.6.3/bin/ghc -v2
  ...
  Using ghc version 7.6.3 given by user at: /opt/ghc/7.6.3/bin/ghc
  Using ghc-pkg version 7.6.3 found on system at: /opt/ghc/7.6.3/bin/ghc-pkg
  Using hsc2hs version 0.67 found on system at: /opt/ghc/7.6.3/bin/hsc2hs
  ...


> but all of those are version specific since they'll break if
> you remove their /usr/lib/ghc-version.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Reid Barton-2
In reply to this post by Evan Laforge
On Fri, Jul 31, 2015 at 2:32 PM, Evan Laforge <[hidden email]> wrote:
On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel
<[hidden email]> 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?

You can specify just the executable name, in which case cabal will search $PATH; or specify an absolute or relative path. So

    cabal install -w ghc-7.10.2
    cabal install -w ghc-7.8.4
    cabal install -w $HOME/my-ghc-checkout/inplace/bin/ghc-stage2

I install the binary distributions with --prefix=$HOME, so that the binaries all end up in ~/bin and I can invoke the version I want easily in this fashion. 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).

Regards,
Reid Barton

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Evan Laforge
In reply to this post by Herbert Valerio Riedel-3
On Fri, Jul 31, 2015 at 11:42 AM, Herbert Valerio Riedel
<[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Sven Panne-2
In reply to this post by Reid Barton-2
[...] 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Erik de Castro Lopo-34
In reply to this post by Evan Laforge
Evan Laforge wrote:

> The recent release of ghc 7.10.2 reminded me of something I meant to
> ask about a long time ago.  Most of the binaries ghc installs are
> versioned (x linked to x-7.10.2), with some exceptions (hpc and
> hsc2hs).  Shouldn't they all be versioned?  Also, 'haddock' is
> inconsistent with all the rest, in that it's haddock linked to
> haddock-ghc-7.10.2.

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.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Wolfram Kahl
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Erik de Castro Lopo-34
Wolfram Kahl wrote:

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

I install cabal-install from debian which just puts it in /usr/bin/
which works fine, with and without sandboxes.

> 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 have not run into this problem with ghc-7.6.3, ghc-7.8.4 and ghc-7.10.2
installed.

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

With a recent version of cabal, run 'cabal user-config diff' to
display what if different between your ~/.cabal/config and what
cabal would install if it didn't exist. Sometimes an older
~/.cabal/config file can cause troubles.

Cheers,
Erik

PS: Please reply to the list and do not CC me.
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Josef Svenningsson
In reply to this post by Erik de Castro Lopo-34
On Fri, Jul 31, 2015 at 10:31 PM Erik de Castro Lopo <[hidden email]> 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.


Josef

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Alexander Berntsen
In reply to this post by Evan Laforge
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

And as mentioned, cabal handles it already.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVv3UIAAoJENQqWdRUGk8BNIwP/1Y2gqn61jgYbq9nRKLYPqTU
fCWC4N1uFjUQWLEzVPX8DxQQiqRF2IBt9jUo/K6Z6k82cz91E9/r2Hfpeyp43Y+M
j+WB38jJhr94dpWHJOGYXZNkSHfR6JUwFKwDM8PmOFvfphEJ79FG0EABFNwr6BPY
XWAY5d5bPoDwiuXgtF50ioRnMAmktDNBQP7f1kV//S7rraNL+qcr7k0EobrK8myw
lfclXg0U5rwre73Nrlm4avJI4Zdtgkw/TMSVkG+OPFRqQiUPnlzHveuzLPR2+J52
fl5WAWBSSWdS1mYCj0KXNGoS1oP8loq70hfb8HG+Gm9MQfq4UxI1YgM62jK66zNM
q8xClsDlqkz4KqHLQkdL1dfFtLT3w5Sqp7P/4ok/8/dij8gvHCFuGn4OIo0rU39z
HHmgbFppGZqpdoGBPfmJFextwvdvs0lcLgODKv1XpZid4k6p2TXhenfDTsiSqkdj
zckFbawoEVs7vjjRW0SUDCgH6EMtQDJEQ0OjlHpYNy1xKwPjJpV2n1Ea8UmZcdmI
g5w+O+0X62tyYJRPDMQVl3QlRMwcc/X2IV/OyU5L39CTcehqkmddiV/r2E7tXlfO
gGr8659SyB4EgG6yfot77nBt8MO5QeKMBSdzYCbfObk6H1Zqe+Z6N7N6ebpVdNz3
NDhsqhx/gyjdNX2tYrMM
=KlSw
-----END PGP SIGNATURE-----
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: simultaneous ghc versions

Brandon Allbery
On Mon, Aug 3, 2015 at 10:04 AM, Alexander Berntsen <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users