library infrastructure roundup

[Isaac Jones]

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