basic haskell DistUtils

[Isaac Jones]

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 <ross@soi.city.ac.uk> writes:

> 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