Hello all, Lots of discussion wrt the library infrastructure has been happening off the list (rather by accident) and I'd like to bring it home a bit. Corrections and extensions are welcome. There is a goodly amount of work and thought already put into a variety of systems that are related to the project. In particular, the build system for fptools is being extended to be more generic, and there is a generic build system for Haskell in the works by the Yale folks. Also HMake is a very cool tool for building haskell programs. We discussed the fact that it would be nice if Hugs had a package list like GHC and NHC have, and similarly it would be nice if GHC (and NHC?) had a way for users to keep a pacakge list in their home directories. I also suggested that it would be nice to have a flag in each Haskell implementation for Haskell extentions which are implemented portably on each system. That is, in ghc, I can use "-fglasgow-exts" to turn on a variety of things which may or may not make my code non-portable. On the other hand, if I had a flag "-fportable-exts" (in Hugs it might be "+portable") I would feel better about using some extentions. There is also a sense that it might be useful for Haskell implementations to provide a gtk-config type tool for letting a build system know where it wants to keep stuff... Alastair Reid put it best:

What is being proposed is that there would be one program distributed in a ghc distribution which:

- is used by ghc and ghc-pkg to find both the global and personal package.conf files:

global_packages <- shell "ghc-config --global-package" >>= readFile local_packages <- shell "ghc-config --local-package" >>= readFile let packages = merge local_packages global_packages

- is used when installing packages to find the platform-, site- and user- preferences for where to install libraries.

(If ghc-pkg didn't have a way to find package.conf, it would be used for that too.)

[I expect that other uses will emerge. e.g., ghci might want to read default flag settings from here, hscpp could read compiler-specific command line flags from here, etc. Also, you'd want a way to dump all config info so that it can be included in bug reports.]

So some paths would be wired in when ghc is installed. This already happens - all that would change is the details of what is wired in and how it is accessed.

The distutils wrapper would _not_ contain absolute installation locations. Rather it would consult ghc-config to determine the platform-, site-, and user- installation preferences and override these (where appropriate) with any build/ installation time preferences that may be supplied. Having GHC provide the configuration file means that distutils only needs to know about ghc-config, it doesn't need anything else wired into it.

I do believe that Alastair also means that there would be hugs-config and nhc-config programs. Are there any big things I'm missing?

From where I'm standing, the action-items seem to be this:

- I am working on an abstraction-layer / wrapper similar to distutils for Python. This is so that people can choose among build systems which fit their needs, and yet allow the community to build tools for package and distribution layered on top of a consistent interface. - Peter Simons (in his words): "my next step will be to come up with a description of "my" project's goal, a repository layout, and a prototype build system. This document can then be discussed, revised, thrown away, and be re-written. :-)" (wrt the build system, you probably will want to talk to Alastair and Nilsson to see what has already been done in this area.) - "Compiler" implementers: hash out ideas for package systems mentioned above. Would anyone venture to follow up with a list of decisions that need to be made? - build system implementors: keep up the good work :) peace, isaac