From: Sven Luther <luther@lambda.u-strasbg.fr>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: Sven <luther@dpt-info.u-strasbg.fr>,
Vitaly Lugovsky <vsl@ontil.ihep.su>,
caml-list@inria.fr
Subject: Re: [Caml-list] OCaml packaging problems
Date: Tue, 18 Jun 2002 15:32:53 +0200 [thread overview]
Message-ID: <20020618133253.GA30437@lambda.u-strasbg.fr> (raw)
In-Reply-To: <20020618145733.A21463@pauillac.inria.fr>
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
next prev parent reply other threads:[~2002-06-18 19:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-22 13:07 [Caml-list] Project Proposals Diego Olivier Fernandez Pons
2002-04-30 9:16 ` Xavier Leroy
2002-04-30 13:28 ` [Caml-list] OCaml packaging problems Vitaly Lugovsky
2002-04-30 15:08 ` Remi VANICAT
2002-04-30 18:04 ` Sven
2002-05-14 8:54 ` Xavier Leroy
2002-05-14 10:45 ` Stefano Zacchiroli
2002-05-14 15:46 ` Xavier Leroy
2002-05-14 11:39 ` Jacques Garrigue
2002-05-14 13:54 ` Michal Moskal
2002-05-14 23:28 ` Jacques Garrigue
2002-05-15 12:10 ` Sven Luther
2002-05-14 13:49 ` Michal Moskal
2002-05-14 22:52 ` Gerd Stolpmann
2002-05-15 1:18 ` Jacques Garrigue
2002-05-15 12:05 ` Sven Luther
2002-05-15 17:39 ` Vitaly Lugovsky
2002-05-16 7:11 ` Sven Luther
2002-05-16 10:24 ` Vitaly Lugovsky
2002-05-16 18:52 ` Stefano Zacchiroli
2002-05-17 16:05 ` Sven Luther
2002-05-17 19:31 ` Vitaly Lugovsky
2002-05-18 10:39 ` Michal Moskal
2002-05-21 19:54 ` Sven Luther
2002-06-13 15:50 ` Sven Luther
2002-06-18 12:57 ` Xavier Leroy
2002-06-18 13:32 ` Sven Luther [this message]
2002-06-18 20:04 ` Gerd Stolpmann
2002-06-19 6:33 ` Sven Luther
2002-06-19 11:09 ` Markus Mottl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020618133253.GA30437@lambda.u-strasbg.fr \
--to=luther@lambda.u-strasbg.fr \
--cc=caml-list@inria.fr \
--cc=luther@dpt-info.u-strasbg.fr \
--cc=vsl@ontil.ihep.su \
--cc=xavier.leroy@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox