
Remember that the code I posted is really just to facilitate
discussion at this point. I'll try to write up a better summary of it
soon. See the bottom of this email for a little more info.
Ross Paterson
The CVS version of Hugs has a simpler mechanism than you're assuming here: a path entry of the form /path/to/dir/* means all immediate subdirectories of /path/to/dir.
That is fine; the hugsWrap script is just included as an example. I wanted to be able to do _something_ for hugs. Either way works fine assuming that hugs can be built with a nice set of default paths to look in, including one in the home directory?
As far as Hugs is concerned, I'm a bit confused. There seem to be three ways a Haskell package can be installed on a system:
- installed using the system (e.g. Debian) package manager - installed by the local administrator in /usr/local (or the equivalent) - installed by users in their home directories
The last two will want to keep packages separate for easy deletion and replacement, but it seems wasteful for the first to do so, since the system package manager keeps track of which files belong to which package.
Indeed. My example system could work in a few ways. debian/rules basically wraps something like: Setup.lhs install-hugs --prefix=debian/tmp --runfrom=/path/to/hugs/extentions --noregister Which can stick stuff anywhere below extentions and as you say, the package manager can worry about deleting them when stuff is removed. The --noregister is nonsensical with the way CVS Hugs works, but other than that, this would be the same. (debian/rules is itself wrapped by "./Setup.lhs bdist-deb") OTOH, the user could say: Setup.lhs install-hugs --prefix=~/path/that/hugs/knows/about And the sysadmin could say: Setup.lhs install-hugs --prefix=/usr/local/path/that/hugs/knows/about The former doesn't work with the basic package registration stuff that I included since it wants to write to /etc/hugs/includes. SimonPJ suggested that I clarify this a bit for people who haven't been following the discussion closely. I hope to put together a lot more information over the next few weeks, but to give you an idea of the use-cases for this tool: End User: - Installs packages with a package system like rpm (basic version works can create debian files, at least on my computer ;) ) - or can run "./Setup.lhs install ghc" to build, install, and register a ghc version of the program (basic version works) Packager: - Can run "./Setup.lhs bdist-deb" to build a skeleton debian package for the system for each of the installed compilers. (this already sorta works!) 3rd Party Author: - Writes a Setup.lhs program, which imports DistUtils.Core (or something) that does most of the hard work. If they have rather simple needs, like hunit, they only really have to include the name of the program, the version, and the names of the source files, and call DistUtils.defaultMain or something. (basically works) - If they have a more complex program, then DistUtils could produce some Makefiles for the project based on the GNU Make systems already underway, or perhaps just some skeleton makefiles for them to fill in. - If they don't want to change make systems, then they can write their own Setup.lhs scripts to wrap their build system to conform to the standard targets, hopefully this will allow targets like bdist-deb to "just work" nomatter the build system. Compiler Authors: - Conform to any changing package management system (can probably wait a while) - may include writing functionality so the compiler can be asked questions about itself - may include altering compilers to read /etc/haskellPackages.conf or something to find out about which packages are installed or where to look for imports. - Include "DistUtils" module with compiler (in exchange, we can hopefully remove some stuff thats getting included with the compilers now) Random Haskell Programmer: - Can use the DistUtils _library_ as a means to create further tools to download, build, install, etc. For instance we might have a function which figures out the dependancies among haskell modules, another function which returns a list of the installed packages. peace, isaac