Simon Marlow
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/