Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Ports-like package management system
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Stefano Zacchiroli <zack@u...>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
On Wed, Jan 30, 2008 at 03:07:14PM +0100, Gerd Stolpmann wrote:
> My suggestion is this: A driver file "Obuild" that descriptively says
> which build tools (out of some generally accepted options) are supported
> by this piece of software. Example for Obuild:
> configure_script: configure
> build_tool: GNU make
> make_bytecode_target: all
> make_native_target: opt
> make_install_target: install
> supports_prefix: true

I like this proposal in general, and the above example targets sound
reasonable. However, I would like to stress that some semantics
associated to the above name should be clarified somewhere. For example,
here is a sampling of questions I've found differently answered in my
experience of Debian packages of OCaml software:
- does the make_install_target above installs bytecode, nativecode,
  both, the "better" of the two?
- does the make_native_target above requires that make_bytecode_target
  has been invoked first?

The answers might seem obvious, but I assure you that there are an
unbelievable number of different combination of them in the OCaml
distributed softwares out there. The compilation of random C libraries
is far more standardized that OCaml's; this is probably our chance to do
the same.

Also, you would need to support "custom" build tools in which you are
just told to run a given command. Extlib for example needs you to run
"./" in order to be installed ...

> What's left out are dependencies. They make only sense as a system,
> and managing a system is a different story. That should be left to
> packagers like GODI or Debian.
> Well, as said, I suggest to leave out dependencies. A dependency error
> in a single uploaded package can make the whole tree unbuildable. Deps
> are outside the scope of loose cooperation.

I don't follow you here.

First of all the OCaml namespace of distributed software ATM is quite
well defined even if we have had so far no common place where to upload
stuff. So we can rely in general on names being unique. Then, I would
like to have in an Obuild file the declaration of which other OCaml
softwares I need to build that one (i.e. I'm talking about *build*
dependencies here, not runtime/development time dependencies). Why such
a requirement isn't reasonable? You are basically proposing a
declarative specification of the build process of a distributed
software, I consider build dependencies a fundamental part of such a

Or where you talking about runtime/development time dependencies?


Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{,,}  -<%>-
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time