From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA12028 for caml-redistribution; Mon, 22 Mar 1999 08:50:32 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA12982 for ; Fri, 19 Mar 1999 21:54:48 +0100 (MET) Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA08686 for ; Fri, 19 Mar 1999 21:54:47 +0100 (MET) Received: from schneemann.darmstadt.netsurf.de (board-20.darmstadt.netsurf.de [194.163.86.148]) by beach.frankfurt.netsurf.de (8.8.5/8.8.5) with ESMTP id VAA07961 for ; Fri, 19 Mar 1999 21:51:52 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by schneemann.darmstadt.netsurf.de (8.8.8/8.8.8) id VAA27546 for caml-list@inria.fr; Fri, 19 Mar 1999 21:54:06 +0100 From: Gerd Stolpmann Reply-To: Gerd.Stolpmann@darmstadt.netsurf.de Organization: privat To: caml-list@inria.fr Subject: Suggestion for a site-lib directory Date: Fri, 19 Mar 1999 20:34:48 +0100 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99031921540505.02442@schneemann> Content-Transfer-Encoding: 8bit Sender: weis Hi, 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 projects. 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 variable. (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: site-lib/ xlib/ xlib.cmi ... asmdynlink/ dynlink.cmi ... ocamltk/ tk.cmi ... - There is a new option -use-package 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 -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------