RFC: External library infrastructure

[Alastair Reid]

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

I was thinking "add all the things that make packages insufficient
to use as an infrastructure" :-)

One thing is autoconf support for those doing ffi.
We might also want conditionals in package specs (cpp enough?).

I don't see Makefiles as part of a cross-compiler story.  Rather, I
see an enhanced package system that includes a subset of makefile
functionality (e.g., Hugs' import chasing and GHC's --make
functionality).

It would be good to have a portable way of specifying most compiler
flags which affect language features.  For example, 

  features = {FFI, MPTC}

would be translated into -ffi and <whatever> for GHC and -98 for Hugs
and would trigger an error in NHC which lacks MPTC.  Flags would only
be standardized as we agree on them and there's be a way to provide
flags in a compiler-specific way to deal with the rest.

>> We might also want to develop a common testing infrastructure for
>> libraries which, ideally, would work with all compilers.

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

That sounds good.  I think we already plan (but haven't scheduled :-))
to do that for the compiler testing side so hopefully a more widely
useful library testing system could come out of it?

--
Alastair