On Tue, May 21, 2002 at 12:54:23PM +0200, Stefano Zacchiroli wrote: > On Tue, May 21, 2002 at 12:07:07PM +0200, Sven Luther wrote: > > Just a quick notice for debian packages and this : > > have you already forwarded this comments to Gerd?
No, i did a group rely though. > > o the name of the dir needs to be coordinated by upstream and there > > should be only one before we adopt it. Ideally it should be possible > > I've already replied to Gerd on the OCaml mailing list asking for > comments from INRIA upstream even if the mail hasn't yet arrivied > because it was delayed by some stupid MTA. > > > o a dual solution (/usr/lib/ocaml/shlibs and > > /usr/local/lib/ocaml/shlibs) woulc be nice. > > agreed and easy, I will put the additional /usr/local/lib line in > ld.conf when installing findlib package > > > o i don't know findlib, so i may be speaking nonsense, but i would > > think it is usefull to have a manual override for specifying dll and > > so files by hand, so we don't have to worry about problems with > > automatic extension detection. > > Are you thinking about overriding the extensions considered as shared > objects or are you talking about overriding the shared objects files > directly? Well, Gerd was speaking about problems with autodetecting dlls and so files, if you have a manual override, then you can workaround those (admitedly rare) problems. > I think that is better to specify with a command line flag which files > are shared objects. Currently to install files with findlib you have to > > ocamlfind install -destdir /foo/bar file1 file2 file3 ... > > I'm thinking about something like > > ocamlfind install -destdir /foo/bar -so foo.so -so bar.so file1 file2 file3 Yes, something such or : ... -solist foo.so bar.so -others file1 file2 file3 (well, doing it the other way around, and you don't need the -other flag i use here (which is not a good name, btw)). > > Usually shared objects are really few so this hardly can be a problem. Yes, ... > > > And since anyway, we do this at package preparation time, there is no > > problem with doing this by hand (there are usually only a few such > > files per package). :))) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
