Haskell library infrastructure coordinator

[Alastair Reid]

Isaac Jones writes:
>  * Standard library search paths might be necessary, and standard
> flags would be useful.  hmake could go some of the way (maybe it
> already does?) in hiding different compiler behavior where possible.

Some of the issues I've found in adapting the fptools infrastructure are:

1) It's possible to install packages in global filespace (e.g.,
   /usr/lib/greencard) or in local filespace (e.g., $HOME/lib/greencard).
   If you're putting it in global filespace, it is appropriate to 
   register it in the global package list (e.g.,
   /usr/lib/ghc-5.04.2/package.conf) but where do you register it if 
   installing it locally?

   The fix seems to be to have ghc-pkg default to recording packages
   in the local fielspace (e.g., $HOME/lib/ghc-5.04.2/package.conf).

   The same will go for any other compiler and for anything that maintains
   a list of installed packages.  There has to be a standard place
   in local filespace ($HOME/...) for the list to be maintained.

   An easy way of doing this seems to be to copy and extend the ghc
   flag --print-libdir which tells you where the global copy is stored.
   That is, we should add an additional flag to tell you where the local
   copy is supposed to be.

2) When compiling and installing libraries with hugs, ghc, nhc, it's
   useful to store it in a directory which includes both the compiler
   name and the compiler version.  For example:

      /usr/lib/greencard/$compiler.$version

   This makes it easy to have multiple versions of your compiler installed.

   It's also useful to be able to find the HsFFI.h file required by the ffi
   extension.

   For this, it would be nice if all major tools provided a way to extract
   things like version number in an easily parsed way.  For example, it'd be
   nice if compilers could act like this:

      $ hc --print-install-info
      compiler = GHC
      major-version = 5
      minor-version = 04
      patch-level = 2
      include-dir = /usr/lib/ghc-5.04.2/include
      global-libdir = /usr/lib/ghc-5.04.2
      local-libdir = $HOME/lib
      ...

   Note that I want the tool itself to print this information not to
   have a separate program which prints the info.  This seems to work
   better if I ask for the library to be compiled and built with a 
   particular compiler (e.g., $HOME/cvs-dirs/nhc98) because there's no
   risk that I'll run the wrong program to get the install info.

3) When installing libraries, it initially seems fine to install the
   greencard library in /usr/lib/greencard.  But then we move onto the
   X11 library and try to install into /usr/lib/X11.  Hmmmm, that doesn't
   work so well.  It'd be good to have some standard suggestions for people
   to use.  Some which spring to mind are:

     /usr/lib/HS$package
     /usr/lib/haskell-libraries/$package
     /usr/lib/haskell-libraries/$compiler.$version/$package
     /usr/lib/$compiler.$version/$package

   Note that with the last, we're using the directory that the compiler itself
   uses so there's a possibility of conflicts.


>  * The make system should be wrapped with a python-style distutils
> system which provides a ./setup.hs with standard targets so that every
> library gets built and installed the same way 

I think it is a great idea to have this extra level of indirection.
It means that people can use makefiles, configure scripts, etc. suited to 
their application, preferences, choice of license, etc. and still play with 
everyone else. Obviously this needs a different version of setup.hs for each 
infrastructure but this hopefulyl isn't too hard.

I think it's a mistake to make it a Haskell script though because that's bound 
to lead to bootstrapping issues.  I'd use a shell script instead.

--
Alastair Reid