Haskell distutils-type system

[Isaac Jones]

Hello Python Community. I bring greetings from the Haskell community
(http://www.haskell.org)

There has been a lot of discussion of late about creating a
grand-unified build & distribution system for "3rd party" Haskell
libraries (those not distributed with the compilers). Python's
Distutils has come up a few times. The Haskell Library Infrastructure
Project's web page is just a wiki page which can be found here:
http://www.haskell.org/hawiki/LibraryInfrastructure. I'm running this
project.

I also wear another hat in that I'm interested in maintaining Debian
packages related to Haskell, so I want to make my job easier by 1)
writing software support, and 2) making it easy for other people to
maintain Debian packages so I don't have to

I've read much of the documentation at
http://www.python.org/sigs/distutils-sig/doc/. I've also made a toy
Python program that uses distutils. It occurs to me that the issues
that were facing the Python community are strikingly similar to those
facing the Haskell community now, except perhaps for the fact that
there are at least 3 very strong Haskell "compilers" that we want to
support.

One idea for this distribution system, which we're calling the Library
Infrastructure Project, is to create a nice gmake-based build system,
document it, and leave it at that. Another idea is to use a
Haskell-based Distutils type system. Now I think that the
Haskell-based system should work out-of-the-box for pure-haskell
modules (no extensions), and maybe wrap a more complex make-based
system where necessary (as when interfacing with C or using
preprocessors). I definitely want to optimize for the common case of
joe-haskell-programmer wanting a nice way to distribute modules to his
friends, but of course I also want to allow Haskell developers to do
more complex things.

The main issues facing us are:

1) there are a variety of Haskell "compiler" implementations, one of
which is an interpreter

2) not all Haskell implementations are available on all architectures
(ghc for instance)

3) just about every Haskell "compiler" and release is
binary-incompatible, (except maybe for nhc98). That is, if we were
going to distribute binary libraries, we'd need different binaries for
ghc4, ghc5, and ghc6. Also we'd need different binaries for profiling
versions of the libraries, etc.

For instance, if I were to create a binary package HUnit, which is a
simple case since its pure Haskell code, I would need:
hunit-{hugs,nhc98} hunit-ghc{4,5,6} hunit-ghc{4,5,6}-prof

And whenever a new version of GHC6 is released (for instance), all of
the packages like hunit-ghc6 would need to be updated at the same
time. That doesn't even get into the issues of the wide variety of
preprocessors that are common in this rapidly advancing language[1].
So all of this suggests to me that we want to keep a global list of
installed libraries and recompile them whenever a new Haskell
"compiler" gets installed. This is why I want an abstraction layer
above make.

So I want to ask you if you can think of any obvious things we should
watch out for if we try to do something similar to what Python is
doing.

Also, there was some mention (in the related "summary of the
Developer's Day session") of Python's distutils creating a Makefile
and wrapping calls to make, is this what you're doing?

Do you / did you find yourself duplicating a lot of what make already
does, ie dependencies, etc, or do you utilize make?

What about configuration, do you typically interface with autoconf
somehow, or does distutils have its own way to figure out
configuration details?

Is a typical distutils setup.py program pretty much like what we see
in the example documentation? The developer provides some meta-data
and gets a distribution tool? Is there any support for more complex
stuff like interfacing with external systems?

Does distutils handle dependencies?

I've hacked together something that creates a source tarball and a
basic Debian package from a Haskell version of the distutils-type
metadata. I can make that available in a few days if anyone is
interested.

peace,

isaac

[1] Haskell is designed to have a "stable" version, Haskell98, and the
compilers come with a variety of extensions so that it is very useful
as a research language as well.

 

[Ian Bicking]

AFAIK Python's distutils doesn't know about dependencies.

It seems clear to me that distutils would have no use for make's
dependencies. distutils is for distribution of modules, not the
iterative development of those modules. When you build a C extension,
you are always going to compile every file, since you are starting from
scratch. Make's dependencies are only for speeding the developer's life
as they change individual files, it's not for the extension user or
installer.

Ian

 

[Donn Cave]

Quoth Isaac Jones <[email protected]>:
....
| One idea for this distribution system, which we're calling the Library
| Infrastructure Project, is to create a nice gmake-based build system,
| document it, and leave it at that.

If it can be plain make, instead of gmake, that would be closer
my idea of "nice". That has been one of Python's strengths since
early on, easy to build on a variety of platforms and doesn't
impose gratuitous requirements like needing GNU make or Perl
(can you imagine?)

| ... Another idea is to use a
| Haskell-based Distutils type system.
....

| What about configuration, do you typically interface with autoconf
| somehow, or does distutils have its own way to figure out
| configuration details?

This is not one of distutils' strengths. I think the answer to both
is "no" - there isn't any useful interface to autoconf, and it doesn't
have a comparable ability to figure out configuration details. The
path of least resistance would probably be something analogous to
config.h.in, a config.hs.in that allows autoconfig to account for all
the options and environmental variables.

Donn Cave, (e-mail address removed)