continuous build

[mzero]

set up Jenkins (or some such) somewhere and configure it to build haskell platfrom

more ambitious ideas:

• support building for different linux installs?
• build-then-install inside a containered target OS?
• after building, use the build system to build several popular and complex things like Pandoc, lens, Yesod, and Snap

for now, just knowing that some linux build works on each push would be great...

[ygale]

support building for different linux installs?

Or other unix-like OSes. Well, even github-integrated travis-ci, with its dead simple interface, was not trivial to set up. They currently support a wide ranging choice of exactly one platform: Ubuntu 12.04 LTS 64-bit. So unless travis-ci begins to support other platforms, which I doubt will happen very quickly, we would need to set up our own buildbot and various OS VMs manually. So unless someone steps up to the plate to do that, I think this bullet point is going to have to be a lower priority.

If we do set that up, wouldn't it be nice if the physical buildbot machine were, say, a Mac Mini Server? Then we could do Mac OS X builds as well. You can get one for under $1000. Perhaps we would be able to get some funding from the haskell.org committee for that; it could also be used for GHC Mac OS X builds. But it all depends on someone having the time to set up the buildbot and all of the various VMs.

[23Skidoo]

Travis added support for OS X recently (sort of, it's currently in beta and you have to e-mail them to get it enabled for your project).

[ygale]

Yeah I saw that. It thought I saw somewhere else that said Mac OS X support is only for private projects, which I interpreted to mean paid projects. But your're right, from that page it seems they would enable that for us if we asked nicely. For Mac OS X we would have to add an extra step to install GHC for each build, since so far only C, Java, and Ruby are pre-installed on the Mac OS X VM (hvr's PPA won't help here :)). And Mark would have to decide how much of a priority this is, since he is already doing the lion's share of HP work on a Mac.

[ygale]

build-then-install inside a containered target OS?

Working on that. But what are the new instructions for a user install of the HP from the HP tarball? Looks like we're not using make anymore, so the old instructions don't apply anymore.

[mzero]

The idea - not fully tested (yikes!) - is that the tarball work essentially as it did before: It was and remains a prerequisite that you have a pre-existing working GHC install. The tarball includes the source for hptool, and expectation is that you build that first, and then you run it. As the tarball has all the package sources already, hptool will notice that and use them instead of using cabal to fetch them.

A chink in this plan at present is that building hptool itself requires cabal, and downloading a few packages. In turns out the old src tarball, also needed a working cabal to bootstrap, and worse needed an active connection to Hackage! We could remove the dependence on cabal by including the sources of the packages that hptool needs as well (even though the platform doesn't use them) and having platform.sh recognize this and do the bootstrap build of hptool directly w/o cabal.

All this said, I'm not entirely sure how useful the src tarball is to people. When I called for how packagers of the Platform used the existing makefile/script machinery, most said they just used the haskell-platform.cabal file!

[mzero]

I'm willing to consider this issue closed... unless you want to keep it open for possible additions to the CI system (like OS X, etc...), though those might be better as separate issues.

[ygale]

As an end user on linux, I have almost never used linux distro HP packages, for myself or at work. We always use the source tarball. In my opinion, the distro installs are great for the occasional casual user, but too invasive for any serious Haskell developer. We generally need to have a number of different GHC/HP installations and switch easily between them, re-install them fairly often, etc. It doesn't make sense to have one particular HP version, the one that happens to be the current version in whatever release of the distro we are on, be the elephant in the /bin/usr room instead of just being like all of the others. It's not the same as on, say, Mac OS X, where you can install several different HP installers.

With the old HP, installation from source was simple and straightforward: create /usr/local/haskell-platform-n.n.n.n, install the correct GHC tarball into it, add that to the PATH, then install the HP source tarball into the same directory.

Perhaps I am wrong, but impression was always that most serious Haskell programmers do something similar. And even if people do use the distro package - they will still need to go the source tarball route to get other versions of HP.

So I was going to do that as the installation test on travis. It should be a good test of a common installation workflow for many end users, plus for the distro packagers. But now I don't know how to do the HP step. It used to be just the usual ./configure ---prefix=...; make; sudo make install, but obviously that won't work anymore. What are the exact instructions now, assuming that the correct GHC bin tarball is already installed?

[ygale]

Here is a suggested installation workflow that would be familiar to people who would be doing an installation from source:

./platform.sh clean

or

./platform.sh [options] build

or

./platform.sh install

where options are --prefix with default of /usr/local, and --ghc-tarball which defaults to use the GHC currently on the PATH if no tarball specified. If a tarball is specified, we install it in a temp dir via the shell and use it to compile hptools, then let hptools install it again in its final destination. Perhaps we can also support --ghc-tarball=download and get it using wget.

For anything fancier than that - the general instructions are to build hptools using cabal, which we assume you know how to do if you want to do fancy things, and then see the output of hptools --help for further information.

Given the extremely late date, I think it's OK to require an open Internet connection as before for this release. We can fix that next time. cabal is not a problem with this workflow.

[ygale]

We are straying off topic for this issue. We should open a new issue for the installation from source workflow on linux.

[mzero]

excellent! agreed on all fronts!

though - I think with that work flow there is no cabal available to build hptool - as cabal the tool isn't part of the GHC release. I think we can (and should) work around this and instrument the src tarball to include all that is needed to build hptool without cabal.