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