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.
Norman
