Suggestion for a site-lib directory

From: Gerd Stolpmann (
Date: Fri Mar 19 1999 - 20:34:48 MET

From: Gerd Stolpmann <>
Subject: Suggestion for a site-lib directory
Date: Fri, 19 Mar 1999 20:34:48 +0100
Message-Id: <99031921540505.02442@schneemann>


I'm currently trying the efuns package, and I've some comments
on the way efuns and other contributed packages could be better
installed. (Note: efuns is only an example.)

Efuns consists of several parts: some libraries that can be used
independently from the rest, and an application. This is rather
typical of contributed packages. Moreover, Efuns loads some
libraries dynamically. The problem is how libraries are located.
The efuns solution is trivial: all libraries are installed in
Ocaml's default location, usually /usr/local/lib/ocaml. This
location has the advantage that it is checked by default such that
all ocaml* commands and the dynamic loader find compiled
interfaces and libraries stored there. The disadvantage is of course
that there is no clear separation between core files and added files,
and that it is difficult to uninstall (and upgrade) packages unless
a package manager is used.

Let's consider another example, ocamltk. Usually this package resides in
/usr/local/lib/ocaml/camltk, and it is not found by default; you have to add a
-I option to all ocaml* commands. If all packages were installed this
way, you would have to do setups for every project that uses such packages,
i.e. modify your makefiles. That's not tolerable if you have many small

As a first solution I thought about an environment variable OCAMLPATH. This
variable declares additional default locations that are searched in turn. The
idea is that you can now specify a default setup, i.e. put all locations into
OCAMLPATH where some package is installed which could be done in your profile.
That's of course more convenient than to maintain a bunch of makefiles.

But it has disadvantages, as there may be namespace conflicts. It is not
unlikely that several packages use the same names for modules (in efuns, for
example, there are some very common names like Time or Parse_file). It would
be better if you could specify which packages should be used.

Because of this I would prefer the following which is a compromise between
the various approaches.

- There should be at least one "site-lib" directory. This could be
  /usr/local/lib/ocaml/site-lib by default.

- You can add further site-lib-like directories by setting an environment
  (Or should the variable override the default? Think of multi-platform setups.)

- "site-lib" is NOT searched directly, but it contains directories where the
  packages can install their stuff. For example:
- There is a new option -use-package <packagename> that searches the package-
  specific directory and has the same effect as if a corresponding -I option
  had been given with the absolute directory path. The difference is that
  -use-package includes a directory that is found upon a simple, unstructured
  package name whereas -I must have a path name (either absolute or relative)
  that may be different on different systems.

- The Dynlink module allows to refer to package directories, too.

- The #use directive can have optionally two parameters:
  E.g. #use "ocamltk", "tk.cma"

This type of overall setup makes Makefiles much simpler to maintain as
references to absolute locations can be avoided.

It would be nice if there were an ocamlinstall command that knows the absolute
location of the default site-lib directory. For example,

        ocamlinstall -make-package xlib xlib.cmi ...

first removes the xlib directory in site-lib (if existent), creates then a new
one and copies the given files to it.

        ocamlinstall -remove-package xlib

simply removes the directory where the named package resides.

        ocamlinstall -whereis-package xlib

simply outputs the directory of "xlib".

What do you think about this suggestion?


Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail: (privat)

This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:21 MET