RFC: External library infrastructure
Hi Folks, It has occurred to us that the GHC community really needs an infrastructure (i.e. like a build system, but more) that people can use for shipping their own libraries independently of GHC. Several people have asked recently if they can ship their libraries with GHC - for a while we were quite receptive to this, but GHC is getting rather "heavy" both in terms of build time and maintenance effort, and we feel it's time to cut back a bit. But we don't want to leave library developers out in the cold. Suppose we had an infrastructure which someone could plug their library source code into, and immediately get - a source tarball which will configure/build/install on a Unix/cygwin system with GHC installed, and provide a GHC package when installed. - skeleton binary packages for RPM, Windows installer, *BSD ports, Gentoo ebuild, etc. The binary packages will require some programmer intervention (such as setting the dependencies correctly), but much of the work can be done automatically. Furthermore, we'd provide links to compatible library packages from the GHC web pages. It doesn't particularly matter whether fptools is used as a starting point, or we pick another existing build system or start from scratch. The important thing is that someone who wants to ship a library can pick up this infrastructure and quickly provide all the above functionality with very little extra work. Comments? Cheers, Simon
Simon Marlow
Hi Folks, It has occurred to us that the GHC community really needs an infrastructure (i.e. like a build system, but more) that people can use for shipping their own libraries independently of GHC.
I'd like to throw the following into the pot: The Hugs and GHC developers work pretty hard to keep the two compilers compatible. For example, the next Hugs release will ship with libraries from the same source tree as GHC uses and the same foreign function interface as GHC and the GHC folk recently gave up a feature they dearly wanted in the foreign function interface in the name of portability. So as people try to come up with a distribution and build mechanism that will work for GHC, it would be good to think about how that same mechanism would work for Hugs too. For example, an extension of GHC's existing package mechanism might work well because it would be easy for Hugs to extract the pieces it needs and the package mechanism has little irrelevant stuff. In contrast a variation on the existing Makefile system would work poorly because the complexity for the library developer of buying into the infrastructure far exceeds the complexity of the task (which for Hugs is overcoming a few minor platform dependencies using autoconf or the like, building any foreign function interface libraries, and overcoming a few remaining Hugs-GHC incompatabilities). We might also want to develop a common testing infrastructure for libraries which, ideally, would work with all compilers. [Of course, much of the above is true if you replace 'Hugs' with 'NHC' but I'm not certain of the exact status of NHC at the moment so I'll let them speak for themselves.] -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
Alastair Reid
[Of course, much of the above is true if you replace 'Hugs' with 'NHC' but I'm not certain of the exact status of NHC at the moment so I'll let them speak for themselves.]
I concur wholeheartedly with everything Alastair says. Between the three Haskell implementations, we have already puts lots of effort into ensuring that the "standard" population of the hierarchical library namespace is as portable as possible. A mechanism to make the packaging of third-party libraries as painless as possible is highly desirable, and rather than target it solely at ghc, I think we should similarly aim for the maximum portability. This can only help the exposure that new libraries get, and reduce the burden on the independent developer. Regards, Malcolm
G'day all. On Tue, Nov 12, 2002 at 05:25:42PM +0000, Alastair Reid wrote:
So as people try to come up with a distribution and build mechanism that will work for GHC, it would be good to think about how that same mechanism would work for Hugs too.
If you will allow me to AOL... Me too! Cheers, Andrew Bromage
participants (4)
-
Alastair Reid -
Andrew J Bromage -
Malcolm Wallace -
Simon Marlow