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:
>   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.=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

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

>   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.