Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Haskell distutils-type system

Reply
Thread Tools

Haskell distutils-type system

 
 
Isaac Jones
Guest
Posts: n/a
 
      07-01-2003
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 nhc9. 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.

 
Reply With Quote
 
 
 
 
Ian Bicking
Guest
Posts: n/a
 
      07-02-2003
On Tue, 2003-07-01 at 16:34, Gerhard Häring wrote:
> > 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.


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



 
Reply With Quote
 
 
 
 
Donn Cave
Guest
Posts: n/a
 
      07-03-2003
Quoth Isaac Jones <(E-Mail Removed)>:
....
| 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, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
playing with berp: python3 to haskell compiler in haskell Alia Khouri Python 0 10-31-2010 08:16 AM
Hubris connects Ruby to Haskell, will there be such a connection between Python and Haskell? Casey Hawthorne Python 3 02-17-2010 10:31 AM
a Haskell a Day Xah Lee Java 10 10-28-2005 07:25 AM
Explanation of macros; Haskell macros mike420@ziplip.com Python 80 11-07-2003 02:22 AM
Re: Explanation of macros; Haskell macros mike420@ziplip.com Python 1 10-07-2003 04:07 PM



Advertisments