PROPOSAL: Remove OpenGL

[trevor@…]

I would like to propose that we remove OpenGL from the spec.

• The standard package sets for ruby and python don't include OpenGL, as it makes the distribution harder to install.
• #55 cites a build failure as a result of the OpenGL dependency.

---

Current heuristics to act as a guide:

• Does it meet a stated end-user need?

• Is there a champion for it?

• Do similar systems include such a library (e.g. Python)? NO

• Is it portable? Yes (but caveat: it is hard to build the C component), to systems that support OpenGL.

• Does it add additional C libraries? Yes (majority of build complaints are about OpenGL).

• Does it follow the package versioning system? Yes

• Is the code of good quality?

• Does it have history? Yes Part of original ghc libs, >10 years old

• Is it on hackage? Yes

• Does it provide haddocks? Yes

• Does it have a test suite?

• Does it have a maintainer? Yes

• Does it require new Haskell dependencies? (invariant: the platform must be closed wrt. deps) No

• Does it have a simple/configure-based Cabal build? Yes

• Does it conflict/compete with existing functionality? No

• Does it reuse existing types? Yes

• Does it follow the hierarchical naming conventions? Yes

• Is it -Wall clean?

• Does it have demonstrated users?
  • It has a non-trivial number of application users (primarily game apps): HPong, HipmunkPlayground, paper-soccer, hbeat, topkata, glome ray tracer, monadius, armada, hyplos, rsagl , frag, whim
  • Some graphics libraries use it: GLFW, FTGL, vect, hieroglyph, reactive-glut, Fungen game engine, FieldTrip, drawingcombinators, graphicsFormats, vector-space, svgfonts, obj, AERN-RnToRm

• Have declared correctness or performance statements?

• Is it BSD licensed? Yes

• Will the maintainer continue to maintain it, as demand grows ?

• Is it popular on hackage?

Yes. It is currently ranked 37 / 1318, or in the top 3% of Hackage. Update. Now ranked 23/2200

[RichardG]

Good 3D integration is a nice feature of Haskell. Will it still be provided via GHC or the GHC Extralibs?

[dons]

There will be no extralibs in the next GHC release. So if something isn't bundled in the platform, it will be available at the discretion of individual distros, and via 'cabal-install'

This is one (of many things) to take into account if we remove a capability area from the platform.

[panne]

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.

[j3h]

Patch to add an --enable-opengl flag for the Haskell Platform Unix tarball

[j3h]

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:

 $ patch -p 1 < haskell-platform-2010.1.0.0-optional-opengl.patch
 $ # I didn't include the result of running autoconf in the patch
 $ autoconf
 $ ./configure --enable-opengl=no

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.

[j3h]

Patch to add --enable-opengl and --enable-editline flags to haskell-platform-2009.2.0.2

[j3h]

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.

[petersen]

Erm, packages can't be build options - a package is either part of the Platform or it is not. :)

Given the comments on usage in hackage and the coming move to OpenGLRaw there doesn't seem to be a very strong case for dropping OpenGL now, which is required by GLUT.

[refold]

Milestone 2009.4.0 deleted

[dagit]

Someone needs to make the call on whether OpenGL stays included or not. If the decision is to keep OpenGL then I can be set to the owner and I'll make sure OpenGL gets updated.

[jim.stuttard]

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?

[dagit]

Jim,

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.

[guest]

Just to add another voice where this has gotten in the way.

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.

[jim.stuttard]

Jason,

As there are 2 major, quite different use cases it seems sensible to have 2 versions. Sorry it's taken so long to respond but I was and am too ignorant to have subscribed here.

[nomeata]

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

Having a decision on this soon will help us stay in sync.

[shelarcy]

Replying to nomeata:

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.

+1

See also: #157, #158, #167

And Jason posted below mail for over a year.

• http://projects.haskell.org/pipermail/haskell-platform/2012-January/001738.html

[MtnViewMark]

OpenGL was updated to a modern release in HP 2013.2.0.0