Browse thread
[Caml-list] Project Proposals
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-06-18 (19:10) |
From: | Sven Luther <luther@l...> |
Subject: | Re: [Caml-list] OCaml packaging problems |
On Tue, Jun 18, 2002 at 02:57:33PM +0200, Xavier Leroy wrote: > > I am going to prepare a new ocaml debian package which will support what > > you suggest, but still be compatible with the current way of doing > > things (using the external ocaml-ldconf program). > > [description omitted] > > Looks good. :))) > > But there are two points i much would like a consensus being attained on : > > > > 1) What will be the exact name of these directories ? It would be a good > > idea, i think at least, if we choose the same name for all > > installations of ocaml, and not everyone choosing it's own directory. > > (or else we could have a ocaml option similar to -where which would > > give a pointer to these directories ? and have the choice of the > > directory highly configurable, maybe a -where_stub or something such ?) > > > > Actually i have the proposition of "shlibs" from you, and "libexec" from > > Gerd and the findlib people. and then i feel myself "stublibs" should be > > a nice name too, especially since it is just the sub libraries we are > > speaking about, and not the .cma and other such ocaml libraries. > > My proposal for "shlibs" was just for the sake of example, and isn't > very descriptive. I like "stublibs" or "libexec" better, actually. I would go for stublibs myself, but the findlib folk seems keen on libexec. Maybe we should have a long discution here on that, or you would decide and we keep that, i don't know, i would need more opinion on this. > > 2) I think it would be nice to distinguish two such directories, > > /usr/lib/ocaml/shlibs for distribution native libraries (the packaged > > ones that follow the rule), and /usr/local/lib/ocaml/shlibs for hand > > installed packages. > > Keep in mind that there is only one OCaml standard library directory. > So, non-packaged libraries tend to install in `ocamlc -where`/LIBNAME, > and would put their DLLs in `ocamlc -where`/stublibs. Hence, > I'm not sure the second directory /usr/local/lib/ocaml/stublibs > would be used a lot. But it doesn't hurt. Yes, altough findlib seems to be able to know about it and install thing in /usr/local/lib, if we need to. > On a related issue, to facilitate the transition from the current > scheme, it might be worth adding /usr/lib/ocaml as a third > directory, at least for the next two releases or so. We will keep the full separate directory stuff active in the meantime, /usr/lib/ocaml is one of those dirs anyway, so there should be no problem. > > And should these two dirs be hardcoded into the ocaml suite, (as are > > /usr/lib and /lib into the C ld.so) ? > > I don't think so. The hardcoding in ld.so seems to come from a desire > to facilitate disaster recovery: even if the ld.so cache or > configuration files get accidentally wiped, a reasonable number of > dynamically-linked utility programs still run. There is less to worry > about wiping OCaml's ld.conf file. Ok, ... But then, i would argue for some more switch for ocaml (an ocamlc -wherestubs or even a ocamlc -wherelocal) so that installation programs not using findlib can have a greater control on where to install their stuff. Friendly, Sven Luther ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners