lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

That's a refreshing point of view, and you might be right.

Looking at this from a build system point of view, all it would need is to have dependencies which are URL, instead of files on the local file system.

Then distribution would become more like just sharing your "makefile". But how do you see this connecting to the platform- specific packaging systems (apt-get, fink, ...)?


Norman Ramsey kirjoitti 12.8.2008 kello 21:55:

I see an increasing problem in that every community comes up with
their own package system, instead of reusing existing frameworks.

That's because there are no usable existing frameworks.

I couldn't agree more.  I have been working on this problem off and on
since 1993, and the situation now is even worse than it was then.
It's become a full-time job just to keep track of the frameworks.
(For example, I'm not as informed about Omake as I'd like to be.)

As someone who hangs out in a bunch of different language communities,
I see two needs driving unnecessary diversity in build/package systems:

 1. Language implementors see that they are serving multiple
    platforms (debian, red hat, bsd, windows, macos, ...), each of
    which has its own native packaging system, with its own way of
    expressing dependencies.  The bad idea: invent a new system which
    works across all these platforms but serves only one language.
    This path was the genesis of 'Lua rocks', for example.  And
    although I can't speak of Ruby and Java of my own knowledge, I
    suspect that Ruby gems and Java beans are similar.  I don't
    really understand Cabal, but to the degree that I do, Cabal fills
    a similar role for Haskell.

 2. The technique of 'smart recompilation', described in a 1986
    journal article by Walter Tichy (who also invented RCS), has
    (again to my knowledge) has been reinvented again and again for
    one language after another---it has *never* been packaged as a
    reusable framework.  I know of two valiant efforts: Clemm and
    Osterweil's "Odin" build tool and Blume and Appel's Compilation
    Manager.  But the Odin people never really had a
    programming-language background, and Geoff Clemm was the only one
    who could extend the system.  And the Compilation Manager, while
    really interesting, didn't make it obvious how to use with
    another compiler---in fact I'm not sure if the hooks to support
    smart recompilation were even exported.

I also see repeatedly that the distinction between the build system
and packaging system is blurry: both have to know about build targets,
dependencies, and so on.

At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public, I urged Simon PJ to consider
taking ghc --make and generalising it to support other languages.
I still think this would be a good project.

There are tools to convert Cabal packages to native packages for rpm,
deb, ebuild and arch. The Cabal format was designed to allow this
translation. This includes dependencies on C libs and external programs.

I think this is an essential property for any language-dependent
packaging system to be successful.  I think this is a very good path
for Haskell, even though Cabal is a work in progress.  What I like is
that it overcomes an impedance mismatch:

 * The developer of a Haskell package is presented with *one*
   packaging interface (Cabal), which will create a package native to
   any widely used platform.

 * The client of a Haskell package treats it like any other native
   package: rpm, apt-get, emerge, or InstallShield just
   *work*---Haskell programs are not marginalized.

Of course this model puts a heavy weight on the shoulders of the Cabal
team, but given the current state of play, I don't see how it is
possible to do better for developers and users.  It's certainly better
than the 'Lua rocks' model, which requires the end user to run both
the platform-native packaging system *and* the Lua rocks packaging
system.  Such an outcome for Haskell is to be avoided at all costs.