Haskell distutils-type system

[Gerhard Häring]

Isaac Jones wrote:
> 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 main issues facing us are:
> 
> 1) there are a variety of Haskell "compiler" implementations, one of
> which is an interpreter :)
> [...] 
> 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. 

I'd recommend to stay away from automatic recompilation for release the 
first release. "Explicit is better than implicit."

> 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?

No, distutils doesn't use make at all. It invokes the compiler and 
linker directly, if it compiles C extensions.

It's actually quite messy: Normally, Python itself is built with an 
automake-based build process, that will create a Makefile from a 
Makefile.in and a pyconfig.h. Installing Pyhton installs the Makefile as 
well, and at distutils runtime, distutils parses this Makefile for 
extracting the compiler and linker flags, among others.

The various compiler and

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

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

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

It parses the Makefile, which is usually generated by autoconf, as I 
described above. Obviously there are systems which don't use the 
autoconf-based build process and where this Makefile and the pyconfig.h 
are created manually.

> Is a typical distutils setup.py program pretty much like what we see
> in the example documentation?

In my setup.py for C exntensions there are usually some 
platform-specific portions. if sys.platform.startswith("freebsd") and such.

> The developer provides some meta-data
> and gets a distribution tool? 

Yes.

> Is there any support for more complex
> stuff like interfacing with external systems?

For writing C extensions? Of course.

> Does distutils handle dependencies? [...]

No. And because most C extensions are quite small, that's not really 
necessary IMO.

-- Gerhard