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
[Caml-list] GODI available for download
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] GODI available for download
Some more considerations on my experience.

> Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
> but godi-ocaml-labltk failed, because it needs some configuration
> options (I see no way to pass them). Since I'm used to BSD packages, I
> go to the godi-ocaml-labltk/work directory, and reconfigure by hand.

I realize now that this configuration problem is going to be very
complicated. BSD packages are OS-oriented: they assume a closed world,
where everything is controlled by the packaging system. So you don't
need to tell them where something is on the system, they already know

With godi, the situation is different. For instance, tcl/tk headers
may be in many places, maybe even several versions of them, and the
user should be able to indicate where to find them. Same thing for
camlimages, lablgl, lablgtk, etc...
My feeling is that there has to be a way to give this information
by hand the first time you install a package, and these parameters
would be reused in following installations. When the package is
installed as a dependency, this may require some interaction from the
Also, the possibility of finishing the work by hand must be left,
otherwise recovering from simple configurations bugs can become

I'm afraid this is just one example of mismatch between an
OS-oriented packager and a language-oriented multi-platform packager.

Another one is the use of makefiles internally and in packages. While
makefiles are not intrinsically bad, they have one big default: they
depend heavily on the behaviour of external commands on the system. If
you have only platform this is not a problem: you just have to check
once that this works, but if you must handle multiple platforms, it is
very hard to be sure that the Makefile is portable.
I don't know how CPAN handles that, but this is going to be painful.
Using an ocaml only tool like ocamake may be an interesting option, at
least for simple packages.

Just some thoughts.
I certainly believe that godi is a big step in the right direction.

Jacques Garrigue

P.S. A small detail, but would it be hard to replace godi_ftp by
fetch? On my system godi_ftp is 351K whereas fetch is only 18K. I
suppose this is also reflected by the size of the sources.
I wonder also if there is a packaging system based on gmake rather
than bmake. It feels a bit strange to install bmake only for internal

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: