Re: [Caml-list] 3.09.3 release candidate 2

[skaller <skaller@users.sourceforge.net>]

On Wed, 2006-09-13 at 17:55 +0200, Hendrik Tews wrote:
>    > I do not understand why you do need .cmo files when you have a library
>    > (gramlib.cma or camlp4.cma) that includes these modules (note that .a
>    > and .cmxa are also available for native linking).
> 
> But with this line of reasoning, plexer.{o,cmx} should not be
> installed either, shouln't it?
> 
>    because these are *camlp4* modules, camlp4 loads bytecode
>    (only) dynamically from a single cmo file (only).
> 
> No, for me it was like that:
> - first I didn't know, there is library with these modules 
>   (how to find out what library contains a given module without
>   grepping through the build log?)
> - linking gramlib does not work, because the module is not
>   explicitely referenced (only during runtime the program does a
>   dynlink on something else that needs the given module)

IMHO the real problem is that Ocaml doesn't provide a standard
build model. It's a set of tools you have to couple together
yourself in an ad-hoc way, which makes it very hard to build
and distribute third party add-ons.

Some 'standardisation' is provided by findlib architecture
with meta-file descriptions.

The problem propagates when upgrading: you have no idea
where all the stuff is that requires recompilation to satisfy
the new ABI.

We need to compare this with Python, Perl, Java, or even Felix, 
to see that much better can be done: these systems find stuff more
or less automatically, have specified layouts, and know when
recompilation is required. This level of automation does not
prevent fiddling with manual builds for special effects,
but it eliminates the need to do so for many applications
and libraries.

In my view, there is no need for Inria to implement such
technology: it can be developed by third parties.

However to be really acceptable

(a) Inria would need to participate in the development
   of the specification
(b) modify the tools to support it if necessary
(c) package the final solution with the standard distro
(d) take over responsibility 

Similar to camlp4: tools like findlib are nice but you
can't write build scripts that depend on them because
not everyone has it, and even installing it won't help
with already installed packages, or packages that
don't themselves support it. If it were in the standard
distro everyone WOULD support it (except for the
special fiddles eg using patched Ocamls etc).

I would note that 'Debian' or 'Godi' still only provide
partial solutions -- they won't rebuild USER code bases
automatically.

The rule I use for Felix is: to run a program you say:

	flx source-code-filename arguments

and everything else must be done by the system.
The result of execution is defined in terms of SOURCE code,
not binaries, so it is the system's responsibility --
not the users -- to locate all the required dependent
sources, compile and link as required if cached copies
aren't up to date, and run the code.

In turn, the user is told how to make this work properly
even for user components (and it is their responsibility
to install the required meta-information).

Not everyone will agree with this particular model
and therein lies the real problem. Inria provides several
ways to participate:

(a) Join Inria
(b) Join Caml Consortium
(c) Put stuff on Humps

none of which really give the community as a whole a political
resolution process such as a Standards committee might,
for the formation of a consensus.

Most of us would agree to defer to Inria on issues such as
the type system -- and most of us probably believe Inria
would like to defer to the community on industrial issues
such as building and distribution models -- but we have
no 'forum' suitable for doing so.

The Python community has a process involving PEPs
(Python Extension Proposals) including web interfaces
to track them, and processes to decide whether or not
to accept them.

I suggest the Ocaml Consortium consider opening up to a class of
members 'ordinary user'. Such people join FREE,
and are admitted if a couple of existing members or
nominated persons vouch for them as bona fide interested
parties. Such members can't spend consortium money,
but they're free to contribute directly to it.
The Consortium, in turn, will provide some resources
to this body of people as it sees fit (eg some
space on a web server, a Wiki, etc).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net