Future versions of the OpenGL package will rely on the OpenGLRaw package, leaving only very trivial dependencies on the C side at build time, not even OpenGL headers. Everything is loaded dynamically at runtime.

I have attached a patch against the Haskell Platform 2010.1.0.0 Unix installer that provides a --enable-opengl flag to the configure script. The flag defaults to "yes", so unless the user supplies the flag, the build is not altered. In order to try it out, unpack haskell-platform-2010.1.0.0.tar.gz and run:

This patch also disables installing the haskell-platform-2010.1.0.0 package into the GHC package database because it depends on OpenGL. I think this patch ought to be relatively uncontroversial because it doesn't alter the contents of the package.

To back up Trevor's argument, I have wanted to install Haskell Platform in server environments when I only want to build non-graphical programs. It would have been nice to benefit from the standardization of Haskell Platform without having to install unnecessary dependencies in my build environment.

I have also added a patch that applies against the haskell-platform-2009.2.0.2 Unix installer that provides the same --enable-opengl, and additionally an --enable-editline flag. Sorry for conflating those two separate features into one patch. Just like the previous patch, this one needs you to run autoconf to generate the configure script before configuring.

How many ISP's have OpenGL installed? Web servers don't provide graphics. This is an obstacle to the adoption of Haskell in the cloud and haskell web services. The workaround requires either installing drm, glproto etc. or cutting GL and GLUT sections from the HP configure script or building all the non-graphics HP libs manually. Is there a better alternative than removing this and GLUT?

I've heard from at least one Haskell user that they wouldn't have gotten started with Haskell if OpenGL had to be install manually.

If OpenGL is removed from the platform then I would like to see different types of platform (Desktop edition, Server edition, etc), sort of similar to what Java does. OpenGL could come with the Desktop edition but the Server edition could quite easily cut out packages that require "screen" capabilities.

I think the keys are: a) to keep it simple to talk about the difference and b) easy to add in the missing capabilities. In this sense, a simple to start subset/super set relationship might work. Eg., Desktop contains everything in Server plus OpenGL.

I want to deploy production servers in the cloud with a minimal image and using haskell platform approved packages as the base. But I do not want to install OpenGL and all the graphical dependencies that come with it (bloats the image, costs bandwidth and time).

I do not mind OpenGL being an haskell platform approved package, but it would be nice to able to select which packages should be installed without either janky patches or manually doing everything.

In Debian, the problems with the old version of OpenGL required by the platform and newer versions required to build on current GHC's, or as dependencies of libraries like gloss, remain.

So we will have to upgrade OpenGL soon. This would make the platform, as shipped in Debian, diverge from what is officially included unless OpenGL gets dropped or also updated to the latest version (which will pull in Tensor and StateVar?).

In Debian, the problems with the old version of OpenGL required by the platform and newer versions required to build on current GHC's, or as dependencies of libraries like gloss, remain.
So we will have to upgrade OpenGL soon.