Support different versions of ghc #882

dmalikov opened this Issue Jan 27, 2013 · 48 comments


None yet

As a travis user I wanna be able to choose ghc-7.6 somehow to build my haskell code with.

So it could be some pre_install action or overriding any other step. Having only one supported version of ghc like now is really poor for any CI system.

It is currently tightly coupled to the Haskell Platform, and thus only supports the GHC version that it supports.

I'd be willing to refactor this to be more like Python, where you can specify versions of Python or PyPy. Example: you could specify the Haskell version or HaskellPlatform (which would default to the current stable release).

Being a sizable change, I am unsure if I need to get a "go ahead" prior and possibly resources (e.g. VM). @gildegoma what do you think?


henrikhodne commented Feb 2, 2013

Does GHC/Haskell have an environment switcher like RVM for Ruby or Virtualenv for Python? Without that, this would be very hard to do.

I know you can switch between major versions (e.g. 6 to 7). I have never tried for minor versions. I'll look into it.

I take it I misunderstood how the cookbooks are leveraged (which seems obvious now): The cookbooks are not invoked per VM raised. You setup VM templates with them and then take a snapshots of each type (e.g. JVM, Ruby, PHP). Correct?


henrikhodne commented Feb 2, 2013

The cookbooks are used to create VM snapshots, correct. Rerunning them on every build would take way too long.

Should have thought of that with as often as I do it myself, my apologies. I'll look into the environment switcher and follow up.

I did find one:

However, I'd be hesitent to use it in production as it seems to currently lack active development: Paczesiowa/hsenv#40

There is a better maintained fork by @tmhedberg, but I am still not sure if Travis is comfortable using it in production:

In addition to hsenv, which, as @rockymadden mentioned, I am currently maintaining in the absence of its original author, there is another Haskell sandboxing tool called cabal-dev. I am not sure whether cabal-dev supports multiple versions of GHC, however, but it may be worth investigating for your purposes.

I cannot really comment on the production-worthiness of hsenv, as I don't know what Travis's requirements are in that regard. Anecdotally, I've been using it for quite some time with few issues other than some bit rot caused by the disappearance of the original maintainer, which has now largely been rectified. I'd be happy to respond to any issues that arise, in any case.

Sooner or later, Cabal itself is supposed to get built-in sandboxing support, which will likely be the ultimate answer to this problem. (For the unfamiliar, Cabal is Haskell's principal packaging/dependency management/build system.) That feature seems to have been "on the horizon" for some time, though, so I can't really say how far off it is.

Since haskell-platform-2013.2.0.0 is released travis should support ghc-7.6.3.

luite commented Jun 17, 2013

Multiple GHC versions can coexist without special tools, their package databases are separate. In general, command line tools like cabal, alex and happy work fine if they have been built with a different GHC version.

For example I usually install GHC on my development server in ~/haskell/ghc-version, then to use a specific version, I just add ~/haskell/ghc-7.6.3/bin or ~/haskell/ghc-7.7.20130525/bin to my path. cabal install then automatically uses the right compiler. Supporting a full Haskell Platform with the correct versions of all binaries can perhaps be done similarly, I don't have experience with that.

Having hsenv installed can still be useful for easy testing against multiple library versions, and it might help for GHC switching, but it's not necessary.

Ditto what luite said. Different compilers don't require special sandboxing (cabal-dev etc), they just need to be installed in different directories.

To be clean about it it would be good to also install separate versions of cabal/alex/happy in each of those individual bin/ directories.

This is currently the one thing stopping me from migrating our flaky jenkins testing process over to Travis CI.

Ralith commented Jun 28, 2013

2013.2.0.0 has been out for a while now, and code is beginning to depend on it. When is Travis going to adopt it? Is there anything us Haskellers can do to help things along? It sounds like all that's necessary for multiple version support, is distinct installation prefixes and appropriate setting of PATH.

I'd be perfectly happy just having the latest stable version, rather than multiple, though.

Latest stable is better than nothing, but it's good to have multiple versions for testing the portability of ones own packages. For example, the linux distro packages lag way behind in GHC versions, and if anything, the average Haskell package is too quick to drop support nowadays.

Supporting the last three or four major releases seems like a good rule of thumb, and is what community members such as Johan Tibbell have suggested.


roidrage commented Jun 28, 2013

If you guys can give us an outline of what we need to implement to make this work, we can look into it.

By outline I mean a series of tools and steps we can use to get for instance multiple versions of GHC installed on our image and having a way to switch between them during runtime.

No problem! Here's a script that will download and install a desired set of of GHC versions:

After running it the $DEST directory will look like this:


That is, it will create self-contained ghc installations within a series of directories. It will also create a single bin directory with links to the fully qualified commands "ghc-7.6.3", "ghci-6.12.3", etc.

In general there are two ways to switch GHC versions for the user:

  • Tell the toolset to use the alternate commands. For example, call cabal install --with-ghc=ghc-7.4.2
  • Set the path so that when the build system looks for an unqualified ghc, it finds the right one.

In my opinion, the second one is much more robust. When trying to set up Jenkins matrix configurations, I've had a number of problems with accidental mismatches of different command versions (e.g. new haddock + old ghc, etc).

Note that the above script just provides the basic compiler. One compromise would be to install full Haskell platform for the latest compiler (7.6.3) and then just the compilers for the other versions. Power users should be fine installing libraries themselves as part of their build script (but it is slow).

The Haskell Platform provides a set of pre-selected standard libraries. From the starting point of having all the compilers installed, if desired, it would be possible to then expand each of them to a full installation of the corresponding Haskell platform. For example, these three:

  • ghc 7.6.3 <-> HP 2013.2.0.0
  • ghc 7.4.2 <-> HP 2012.2.0.0
  • ghc 7.0.4 <-> HP 2011.4.0.0

This could be done with something like:

export PATH=$DEST/ghc-7.6.3/bin:$PATH
tar xzvf haskell-platform-2013.2.0.0.tar.gz
cd haskell-platform-2013.2.0.0
./configure --prefix=$DEST/ghc-7.6.3/ 
make install

The nice thing about this is that you'll get a different version of the executables cabal/alex/happy in each of those separate installations. In theory it should be ok to always use the newest for those, but I've run into problems when trying to get away with uncommon combinations.


joshk commented Jun 28, 2013

I have chatted to the team and we would love to add a Haskell cookbook with multi version install!

We would greatly appreciate it if someone could help create a chef recipe PR for travis-ci/travis-cookbooks

We then need to look into how we do version switching, maybe we can just update the path for now? maybe someone can help us with a small tool to help with this?

Any and all help is greatly appreciated with this, and will allow us to get it live faster.

We would greatly appreciate it if someone could help create a chef recipe PR for travis-ci/travis-cookbooks

It will be great if someone provide minimal instructions about how to use existed haskell cookbook with travis-boxes (you guys use it for development, right?). My last effort ends with error and I've found no answers about what am I doing wrong on the #travis irc channel.

Or it will be awesome to have some role with all necessary attributes and imports of haskell cookbook recipes to make it available to test in vagrant with chef-solo.

Are there any benefits from having multiple ghc versions installed the same time? As for me, single ghc is enough for a single build. As a travis user I just wanna choose ghc compiler version from the last 3 when I'm configuring my build project.

I just wanna say that «different» in the subject of current issue is not equals to «multiple».

Is there any chance of support for newer-than-stable GHC versions? As part of some of the programming I'm doing, I require a fairly recent GHC, often a HEAD version. At the moment I'm basically cloning the whole GHC tree every single time, compile it, and then run the actual compilation and tests of the program I'm working on. It seems kind of a waste to spend the 45-50+ minutes just compiling HEAD every time (especially considering that it depends on the phase of the moon whether GHC compiles in under 50 minutes assigned to the test time) every single time, just to run a 30-60 sec compilation + tests.

While it's probably unreasonable to ask for a HEAD binary on the system, would it not be possible to compile a nightly (or bi-daily or whatever frequency is deemed appropriate) version and make it available?

@dmalikov Programs relying on the GHC API benefit from multiple versions. It's useful to test whether the changes you made will even work for the version of GHC from 6 months ago. It's not unusual that they don't and changes where something will build with HEAD and won't with stable (or vice-versa) are not uncommon. Similarly for revisions of the scope of 7.4 and 7.6 etc. I don't believe you have to worry about the really large revisions such as the difference between 6.* and 7.* though.

@Fuuzetsu its really really unreasonable to try and have GHC head as part of this, GHC head is often in various states of not quite working or massing wildly unstable changes (to the APIs, the backend, and ).

Would be reasonable to (eventually) have GHC versions that are out but don't yet have a Haskell Platform distro, but thats adding more complexity needlessly.

One thing worth noting: Would be REALLY handy to have LLVM versions installed with the corresponding GHC versions that support it. GHC <= 7.6.* (those that have the working llvm backend, so 7.6 and i believe 7.4 too) will play nice with the various LLVM CLI tools for LLVM-3.2 .

When GHC 7.8 comes out, it'll only play nice with llvm versions 3.3 or newer (or maybe its that ghc < 7.8 won't play nice with LLVM versions > 3.2 ), i'll have to check that when it rolls out.

I can't speak for other folks, but some of the libraries i write don't make sense wrt performance or having them in haskell without llvm on hand.

@Fuuzetsu well I understand that it is nice to have your code work with many GHC versions. But 3 different travis projects with 3 different versions of ghc seems to be more useful than 1 travis project with separate build steps for checking each of them.

I agreed, that it will be great to have possibility to build your code with 3 different versions of ghc, but I don't think it should be done in single travis project.


joshk commented Jun 29, 2013

Just to make it clear to everyone, the ideal end result of adding support for multiple Haskell versions is so projects can test against multiple versions each time they push to GitHub.

Just like all the other languages we support, we want to allow for users to select either a particular version to test against, or multiple versions.

As for Haskell Head, sorry but I don't think this is feasible right now, I would suggest you look at compiling a version weekly and have Travis download and install that compiled versions, thus speeding up your test runs.

If you have any questions or concerns, please fire them my way :)

@joshk super reasonable, and any way that doesn't require chef literacy to help out, please let us know :)

luite commented Jun 30, 2013

@cartazio we've been running GHC HEAD (with a few patches) for the ghcjs tests for a while, dowloading prebuilt binaries as joshk suggested, and it works ok:

I rebuild the binaries every few weeks, checking them first before replacing the archive on the web server. It's just one command with vagrant after setting up the build script (but it takes a few hours to build):

These recipe should be used with node attributes like that:

      :haskell => {
        :multi => {
          :ghcs => {
            "7.6.3" => {
              :platform_version => "2013.2.0.0",
              :default => true
            "7.4.2" => {
              :platform_version => "2012.2.0.0",
              :default => false
            "7.0.4" => {
              :platform_version => "2011.4.0.0",
              :default => false

Please someone take a look at it, I'm feeling kinda unconfident about availability of packages installed from the platform.

Could someone please update status of ghc-multi? All necessary pull-requests are merged, so what is going on know? Is there something that could be done not just by travis-ci guys?

dmalikov commented Aug 4, 2013


original was made by Roman Cheplyaka


joshk commented Aug 5, 2013

Hahahaha, ok, you zinged us good and proper.

I am working on some VM updates which would include this, I'm sorry for the delay.

But might I say, awesome cartoon! :)

On 4/08/2013, at 10:33 PM, Dmitry Malikov wrote:

Reply to this email directly or view it on GitHub.

bennofs commented Aug 23, 2013

What's the current status of this issue? Is there still anything that's missing?

@ghorn ghorn referenced this issue in ghorn/jacobi-roots Sep 13, 2013


travis-ci integration #2

hvr commented Oct 18, 2013

Fyi, I've hacked up a PPA with multiple GHC .debs which seems to work fine; As an example using all GHC versions, see the build status for filepath package: Build Status

additionally, many new libraries / haskell code bases use features that require a GHC newer than 7.4. Currently to be able to use Travis, they need to basically have their build process install a newer GHC first, before the build can commence! This likely adds a bit to net build times and bandwidth utilization too (which may be slightly valuable to travis folks :) )

@hvr , nice and working well solution, great!

  1. Any ideas how to visualize this build matrix with many status buttons for all of ghc versions?
  2. Is there a way in apt to have live package (like -9999 in gentoo)? Having a ghc-7.8 package with the latest HEAD of 7.8 will be awesome.

Fantastic! Can't wait to try it.

This question may reveal ignorance of both travis and apt, but is that "ppa:hvr/ghc" repository fetching from somewhere local to the Travis cloud machines?

hvr commented Oct 19, 2013

@rrnewton probably not, but it's a common practice for providing alternative versions of tools for Travis-CI (e.g. or also; moreover, I've tried to keep the .debs small...

Well, anyway, I see builds completing in two minutes so it can't be that bad!

hvr commented Oct 19, 2013

@dmalikov I have no idea about 1), as for 2) I'm not sure what that is; however HEAD of GHC does carry a usable version in the style of 7.7.20131019 containing the date which could be used as-is for versioning a ghc-7.7 package.

hvr commented Oct 20, 2013

FYI: I've just uploaded a new ghc-head package to the PPA, see GHC HEAD Snapshots for more details.


gildegoma commented Oct 25, 2013

@dmalikov any plan to update Haskell chef cookbook to use @hvr's PPA?

We've started using @hvr's PPAs -- they're great. Quick question though... does anyone else have a recommended PPA install to (quickly) bring up a version of happy and alex? (We can install from source each time, but that slows the build.)

@gildegoma what logic haskell cookbook should have to support @hvr's PPA? It seems to be that all necessary configuration could be already defined in .travis.yml configuration.

Btw, recipe[haskell::multi] is totally useless so it could be removed - only these changes could be done now :)


gildegoma commented Oct 25, 2013

Sure PPA solution is awesome, and with additional speedup from upcoming APT caching feature, it sounds bad to have (rapidly outdated) preinstalled versions on the VM image.

So 👍 to strongly clean haskell cookbooks, and only preinstall stuff that make sense, if any.

On the other hand it is certainly worth to extend travis-build to offer some nice fashion style to define the matrix build (with good defaults to keep .travis.yml simple). So something like following (similarly to other languages):

language: haskell
  - ghc-7.6.3
  - ghc-7.6.2
  - hp-2013.2.0.0
  - ...

So proposed Goals: cookbook cleanup and more end-user comfort!

hvr commented Oct 25, 2013

@rrnewton is the version of alex & happy contained in Ubuntu Precise too old?

$ dpkg -l alex happy
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                    Version                 Description
ii  alex                    3.0.1-1                 lexical analyser generator for Haskell
ii  happy                   1.18.9-1                Parser generator for Haskell

byorgey commented Nov 5, 2013

@hvr would it be possible to add a cabal-1.16 package to your PPA? Some parts of diagrams currently can't build with cabal-1.18 (since cairo can't).

hvr commented Nov 5, 2013

@byorgey a cabal-install-1.16 .deb should be available as of now... Cabal-1.16 otoh is part of GHC 7.6.x

dmalikov commented Feb 3, 2014

what else should be done here?


joshk commented Feb 3, 2014

I think everything is live and working well, are there any issues?

dmalikov commented Feb 3, 2014

yep, I think it might be closed now


joshk commented Feb 3, 2014


@joshk joshk closed this Feb 3, 2014

@hvr hvr referenced this issue in haskell-CI/haskell-ci Jul 14, 2015


Investigate ways to better manage updating the travis file #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment