RE: Ideas for library infrastructure
[oops, accidentally sent the message before I'd finished it...] Ralf Hinze writes:
I like Andres' proposal. It puts some burden on the compiler writers (but this work has to be invested only once) and considerably simplifies things for the library writers.
Putting the burden on the compiler writers is exactly what we want to avoid - us compiler writers tend to be too busy writing compilers! Instead, what I would like to see is a separate library infrastructure that smooths over the differences between systems and compilers, and provides something that library writers can just plug their library sources into. I don't think we need to (or indeed, should) go as far as specifying installation locations, or extra tools that compilers should provide. All this should be embodied in the library infrastructure, which is written once and maintained by a single group of individuals. Cheers, Simon
[oops, accidentally sent the message before I'd finished it...]
Ralf Hinze writes:
I like Andres' proposal. It puts some burden on the compiler writers (but this work has to be invested only once) and considerably simplifies things for the library writers.
Putting the burden on the compiler writers is exactly what we want to avoid - us compiler writers tend to be too busy writing compilers!
Instead, what I would like to see is a separate library infrastructure that smooths over the differences between systems and compilers, and provides something that library writers can just plug their library sources into.
I don't think we need to (or indeed, should) go as far as specifying installation locations, or extra tools that compilers should provide. All this should be embodied in the library infrastructure, which is written once and maintained by a single group of individuals.
Cheers, Simon
I do not really see a conflict between my proposal and Simons statement here. The central point, so I think, of my proposal is to distinguish and clearly separate two phases: One phase is what the library writer has to implement to install a library in a central location on a system. Of course, this specification should be compiler-_independent_, and could be placed in a to be written standard that could be maintained by an independent group of people. The other phase is what "the compilers should do" to make a so-installed library access-ready for the particular system. BUT, this phase does not have to be an integral part of the compiler and as such could also be implemented as a set of compiler-specific tools (or even _one_ tool) by an independent group of people as well. The important point is that this is something that can be expected to be present by the library writers, so they do not have to care about how it works. I do not quite understand your last paragraph: You say we should not specify installation locations but then say it should be "embodied" in the library infrastructure. How do you mean that? I assumed you were proposing to get away from one central distribution of all libraries that is shipped together with the compilers toward an easy possibility to selectively install and upgrade single libraries. So, certainly, we _do_ need some kind of standard behaviour what should happen upon installation, but that behaviour _should_ be part of the specified library infrastructure and as such not be a burden on the compiler writers. Best, Andres -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de
Andres Loeh writes:
I do not quite understand your last paragraph: You say we should not specify installation locations but then say it should be "embodied" in the library infrastructure. How do you mean that?
Let me be more concrete. 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. That's it. No need to specify installation locations, or any procedure that must be followed by libraries to install or remove themselves. It's all supplied by the library infrastructure. There are a couple of other things that we might want to do to better support systems that don't have a good package management system: - a way to uninstall a library that was installed with 'make install'. - a way to build generic binary distributions. I view these as optional: 95% of the systems we're interested in supporting have good package management systems that we should make use of. An alternative, which some people have been suggesting, is to take on more of the tasks of a package manager (ala Python's distutils). That's fine, but IMHO we don't need to go that far. Cheers, Simon
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/
On Tue, Apr 29, 2003 at 01:58:08PM +0100, Alastair Reid wrote:
It's worth pointing out that the existing GHC Makefiles provide a lot of the infrastructure we need. [...] 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.)
For Hugs, is that the modest extension to search paths you raised? (allowing a path entry like /path/to/package/directories/* to stand for all immediate subdirectories.) There are two cases I can see: - your source package is built as a binary package or port for some system. All the modules for such packages might as well be stored in in a single hierarchy. The system's package manager should take care of overlaps, clean uninstalls etc. This requires no extensions. - someone wants to install your source package into their Hugs installation. You want to keep such things separate from those managed by the system package manager, and from each other, and for that the search path extension would be useful.
participants (4)
-
Alastair Reid -
Andres Loeh -
Ross Paterson -
Simon Marlow