Re: [Caml-list] Re: [OSR] Ports-like package management system

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mittwoch, den 30.01.2008, 14:37 +0100 schrieb Stefano Zacchiroli:
> 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?

Fully agreed that we need a reference document for this.

> 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
> "./install.ml" 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.
> <snip>
> > 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
> specification.
> 
> Or where you talking about runtime/development time dependencies?

See, this question already demonstrates that dependencies are a not so
easy concept. It is at least difficult to reach a common understanding
what would have to be listed as dep and what not. We have dependencies
that come into play at different times, and there are also conditional
dependencies (i.e. you need this software only if you want to build this
special feature). Then there is the question of how detailed the
dependency relation is (versions, or about allowing to have only parts
of software units as dependency).

A formalization of deps needs some complexity in order to be useful, but
that makes a common understanding of them more difficult. I have some
doubts that we find a balance here, so my advice to leave a formal
description of deps out.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------