Ideas for library infrastructure
Alastair Reid
alastair@reid-consulting-uk.ltd.uk
Tue, 29 Apr 2003 13:58:08 +0100
Simon Marlow <simonmar@microsoft.com> 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 debian.org, redhat.com,
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
libraries.
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 alastair@reid-consulting-uk.ltd.uk
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/