[Haskell-cafe] Cabal (was: Compilers)

[Thomas Schilling]

When people say "Cabal" they often mean two different things (or both).

Cabal-the-library (package "Cabal") knows how to use standard Haskell
build tools but it is not a very flexible or easily extensible build
tool (it relies on ghc --make for one, don't know how it does it for
other compilers).  Cabal was originally intended to be extensible via
Haskell, but this has its disadvantages (such as API breakage).
However, the .cabal file format seems to be very useful for packaging
purposes.

Cabal-the-install-tool (package "cabal-install") is actually a
different program that sits on top of Cabal-the-library, and it is in
fact what really provides the real advantages.  Together with Hackage
this is what provides the killer feature of "cabal install foo",
however it relies on the building features and meta-data of Cabal.

FWIW, here's a small SLOC breakdown of Cabal-the-library (about 1 month ago):

  7087   Distribution.Simple (the build system)
  2127   Distribution  (mostly parse utils and data types)
  1304   Distribution.PackageDescription (similar)
    284   Distribution.Compat  (so that it remains haskell98-compatible)
    136   Language  (definition of language extensions)

The problematic part here is the first one, but it is needed if you
don't want to rely on tools like 'make' to be installed (which the
packaging aspect of Cabal-the-library and Cabal-the-install-tool) rely
on.

(FYI, here're the numbers for GNU make:

SLOC    Directory       SLOC-by-Language (Sorted)
21197   top_dir         ansic=21157,sh=40
4121    config          sh=4121
1658    glob            ansic=1658
1247    w32             ansic=1247
1075    tests           perl=1049,sh=26
16      po              sed=16
0       doc             (none)


Totals grouped by language (dominant language first):
ansic:        24062 (82.08%)
sh:            4187 (14.28%)
perl:          1049 (3.58%)
sed:             16 (0.05%)

So that's over 20000 SLOC, but, of course, for a more powerful tool.
So I presume the 4x more code remark by John was about the Makefile
rules to implement something similar to the Simple build system part.)

2008/11/29 Matthias Kilian <kili at outback.escape.de>:
> On Sat, Nov 29, 2008 at 11:31:52AM -0800, Don Stewart wrote:
>> > I don't see any advantage in Cabal, except that a .cabal file
>> > provides some metadata and dependency information that can help the
>> > build.
>>
>> And we have tools to automate the packaging of cabal-specified code.
>> So for example, there are already native packages of LHC, but not of
>> JHC.
>>
>>     http://aur.archlinux.org/packages.php?ID=21749
>>
>> Because of the automatic packaging for cabal-specified software.
>
> Oh, maybe I'll write similar tools for OpenBSD ports some day (when
> I've enough time). Yet I consider this (useful) configuration and
> dependency information metadata.  IMHO, Cabal is nice for specifying
> this metadata, it maybe nice wrt hackage, some people even may like
> to just cabal-install something and go ahead, but this are already
> too much tasks it's trying to fulfill, leaving alone Cabal as a
> *build* tool.
>
> I'm probably biased, because I had so much trouble with ghc and the
> Cabal/make maze, so I may be a little bit unfair (because ghc's
> requirements are more complicated than just an ordinary program or
> library). However, I really believe in the unix philosophy (one
> tool for one task), and Cabal clearly doesn't follow it.
>
> There's an example for a tool capable of dependency and (to a certain
> degree) configuration management in the java world: ivy
> (http://ant.apache.org/ivy/). Well, they added a lot of bload since
> they moved to apache, and of course one could question why everything
> has to be XML, but the basic idea was: deal with dependencies, add
> support for repositories containing dependencies in several versions,
> but nothing more. No build tool, no packaging or install tool. Yes,
> it's tightly coupled with apache-ant, but if you have an ivy-file,
> there's nothing stopping you from converting the information contained
> in this file to some includable makefile snippet.
>
> I didn't have a very close look at the ghc-new-build-system yet,
> but I think the idea here is basically the same: use the .cabal
> files (and the Cabal library) to generate files that then are used
> by make(1) to do the real work.
>
> I hope that I make at least a little bit sense. The problem I've
> with Cabal is that it tries to be the swiss army knife of dependency
> and configuration management, building, packaging and installation,
> but like those swiss army knifes on steroids (with too much features),
> it doesn't fit in you pocket any longer.
>
> Ciao,
>        Kili
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Push the envelope.  Watch it bend.