> 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 _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users