On Sat, Dec 10, 2011 at 15:45, Xavier Leroy <xavier.le...@inria.fr> wrote:
> 2- As pointed out already in this discussion, it's not on the Caml compiler
> that community efforts are most needed. For example, the most impactful
> action that his community could take, in my opinion, is to adopt and embrace
> a common packaging system like Cabal for Haskell.
This one piqued my interest somewhat. I should refrain from
commenting, but I can't help myself.
What makes the Cabal infrastructure successful is that it is three
different types of systems in one. First, there is hackage which
provides a package repository of "blessed" packages - online search of
the repository and general dumping ground of rotting packages. In
other words, a perl CPAN for Haskell. Quality varies a lot, but at
least there is a go-to place when searching for packages.
Second, Cabal provides a system for automatically building packages.
That is, if you have cabal, chances are that you can just blindly ask
it to build the source code and you are done.... when it works.
Thirdly, Cabal provides dependency tracking among packages. That is,
given a package, you can easily fetch its dependencies and build
another version of the package yourself.
That said, my personal opinion, which probably not means much as I
don't currently write scores of Ocaml or Haskell source, is still that
Cabal is somewhat overengineered. Usually you end up with trouble when
you try to build new packages. If you forget profiling flags, you have
to rebuild essentially everything. Multiple versions of packages
creates headaches when trying to use them (think the diamond-problem
in a subtyping setting with multiple inheritance or functors without
sharing constraints). And when I build Haskell source, I usually end
up cursing the hell out of Cabal :)
Erlang has a tool, doing parts two and three above: rebar. This tool
is fundamentally simpler than Cabal. Its dependency tracking is
essentially download instructions from software repositories and
that's it. Packaging is done by creating the equivalent of static
binaries .. dependencies are shoved into a release of an erlang
runtime with all the necessary modules ready into a selfhosting,
selfcontaining system. The approach is *much* simpler, but it works
tremendously well. Even if it doesn't handle the problem of the
diamond. It also allows different software to use different versions
of libraries, but it doesn't really solve dependency convergence (that
is yet another name for the diamond problem: A needs B and A needs C -
but B needs D in version 1 and C needs D in version 2):
digraph {
D -> B -> A;
D -> C -> A
}
In my experience, it is the simple solutions that works best, even if
they can't handle certain scenarios. In some sense a certain amount of
limitation is more a virtue than a curse. I'd also suggest splitting
the search and indexing part from the dependency tracking and building
part. They are far enough apart that they can be solved each by
themselves.
Finally there are two other things I would recommend one investigates:
FreeBSD ports or Mac OSX homebrew for the indexing part. And pythons
virtualenv (Ian Bicking was the original author). Virtualenv allows
you to build a "virtual environment" in which you install python
packages, which are distinct from the system installation. Of course
you can symlink system libraries into the virtual environment, but it
also means that programs can live next to each other and the
sandboxing going on solves a lot of dependency problems in a simple
way.
In other words, to solve this, I'd much rather try to rig the
excellent Ocamlbuild and Ocamlfind infrastructure such that it
incorporates some of the above things, ... that is if it doesn't do
that already...
--
J.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
