Version control systems

[Norman Ramsey]

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