Ideas for library infrastructure

Alastair Reid
Tue, 29 Apr 2003 13:58:08 +0100

Simon Marlow <> writes:
> The library writer provides:
>    - library sources (.hs, .c, etc.)
>    - documentation
>    - meta-information about the library (the package spec
>      for GHC, for example).
> The library infrastructure provides:
>    - a build system supporting 'make install' for Unix-like
>      systems (inc. cygwin) with any Haskell system.
>    - tools to help you build packages for various OSs: an 
>      RPM spec file, a Windows installer, etc.

It's worth pointing out that the existing GHC Makefiles provide a lot
of the infrastructure we need.  I am trying to package up GHC and Hugs
versions of the X11 and Win32 bindings and of the HGL and am trying to
use the existing GHC-provided infrastructure to do that.  I see my
goal as being to provide a traditional source release with all the
usual stuff that involves:

  - Version numbers for the release (very important - random cvs snapshots are
    hard to provide support for)
  - Configuration hooks (e.g., autoconf)
  - Makefiles
  - Release notes that say what it's for, who to report bugs to, etc.
  - Documentation

I'm not planning on trying to build a Debian, Redhat, FreeBSD,
etc. package, or upload packages to,,
etc. because I think it is better for other people to (continue to) do
this.  I only use one of these systems routinely so it's hard to test
them and it takes some effort to get yourself registered as the
maintainer.  I think this should continue to be done by people who are
usually not the library authors and suspect that things will work more
smoothly if, for example, all the Hugs versions of libraries for
Debian are handled by a single person who makes sure that the packages
they build meet current standards, deals with bug reports related to
the packaging and forwards bug reports to the authors of the

I've previously objected to using the existing GHC Makefiles with
Hugs, etc.  since they seemed like overkill for the application. I now
withdraw that objection for a bunch of reasons:

- Libraries need a lot of other tools besides the compiler ---haddock,
  sgml2doc, latex, greencard, c2hs, etc.--- for which the Makefiles
  are wonderful

- The infrastructure has become simpler.

  As long as you're not building a funny version of GHC, it's really
  not that hard at all.  Indeed, I found it to be quite simple just
  copy Sven Panne's excellent example in his OpenGL and GLUT libraries
  and expect it would be trivial if we were to actually document it :-).

  [There is, of course, documentation for the existing GHC
  infrastructure.  This is great but what's needed is a brief tutorial
  in the tiny, tiny amount which you need to do and understand to use
  that infrastructure with a typical library - where 'typical'
  includes things like using the foreign function interface, linking
  with C libraries, generating Haddock and other documentation, etc.]

- If our focus is on providing binary distributions of packages, then
  portability of the infrastructure is much, much less of an issue than
  if we are providing source distributions.

  With binary distributions, the infrastructure has to work for
  package builders, library authors and those who like to live on the
  bleeding edge.  With source distributions, the infrastructure has to
  work for many, many more people so it has to be more portable and 
  have fewer dependencies.

Of course, some changes are needed in the GHC infrastructure to make
them useful for this purpose.  
- The most obvious are adding additional targets and hooks so that they
  work with Hugs and NHC.  (At least for Hugs, this also requires
  extensions to Hugs to support packages in some way.)
- Some less obvious changes are that the infrastructure is currently
  designed for bootstrapping GHC and so some make rules use the 'just
  constructed' GHC or the 'just constructed' GreenCard - concepts that
  don't really apply when you're only building libraries.  So far I have
  about 10-15 lines of changes (in about 2000 lines of makefiles) - I
  expect this will climb up to about 50 or, at most, 100 lines of
  changes as I add support for Hugs and NHC.
Alastair Reid         
Reid Consulting (UK) Limited