Haskell distutils-type system

Discussion in 'Python' started by Isaac Jones, Jul 1, 2003.

  1. Isaac Jones

    Isaac Jones Guest

    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.
     
    Isaac Jones, Jul 1, 2003
    #1
    1. Advertising

  2. Isaac Jones

    Ian Bicking Guest

    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
     
    Ian Bicking, Jul 2, 2003
    #2
    1. Advertising

  3. Isaac Jones

    Donn Cave Guest

    Quoth Isaac Jones <>:
    ....
    | 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,
     
    Donn Cave, Jul 3, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee

    a Haskell a Day

    Xah Lee, Oct 26, 2005, in forum: Java
    Replies:
    10
    Views:
    636
    Wil Hadden
    Oct 28, 2005
  2. timw.google
    Replies:
    1
    Views:
    558
    Serge Orlov
    May 11, 2006
  3. Luis Alberto Zarrabeitia Gomez

    distutils, No module named numpy.distutils.fcompiler.conv_template

    Luis Alberto Zarrabeitia Gomez, Mar 30, 2009, in forum: Python
    Replies:
    0
    Views:
    1,356
    Luis Alberto Zarrabeitia Gomez
    Mar 30, 2009
  4. Casey Hawthorne
    Replies:
    3
    Views:
    350
  5. Alia Khouri
    Replies:
    0
    Views:
    255
    Alia Khouri
    Oct 31, 2010
Loading...

Share This Page