RFC: External library infrastructure
Simon Marlow
simonmar@microsoft.com
Tue, 12 Nov 2002 17:56:13 -0000
> I'd like to throw the following into the pot:
>=20
> 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.
>=20
> 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.=20
Absolutely. I didn't mean to sound so GHC-centric. It would be great
if the same infrastructure supports multiple compilers/interpreters.
> 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).
Could you be more concrete? What extension of the package mechanism did
you have in mind? (personally I had in mind a standard autoconf +
Makefiles story for the build system, but I'm sure there are better
ways).
It'll be tricky to balance the requirements of a glorious
all-encompassing infrastructure with keeping a low "buy-in" cost (as you
put it), but that must be one of the goals or we won't have achieved
anything.
> We might also want to develop a common testing infrastructure for
> libraries which, ideally, would work with all compilers.=20
Right on. I'd like to propose we start from GHC's current testing
system. It's a small collection of Python scripts (about 900 lines),
and is designed to be compiler-independent, although I haven't used it
with anything except GHC yet.
Cheers,
Simon