Re: ocaml-doc patch for /usr/share/doc/ocaml
Hi,
sorry for not having monitored this m.l. in these days, but you know...
holidays are for working hard on the ever growing to-do list, no? ;-)
> > requires=""
> the _findlib_ packages on which this one depends
Exactly.
> > archive(byte)="lablgtk.cma gtkInit.cmo"
> > archive(native)="lablgtk.cmxa gtkInit.cmx"
> object that are added while linking (prepending them to the user defined
> sources, even walking through package ancestors as defined by
> "requires")
I want to add something more: the words byte and native are just labels.
You are free to add any list of labels you want in an archive() entry.
The semantics is that the archive entry that matches more the list of
labels provided in the user Makefile is the one that will be used.
Moreover, byte is automatically added by "ocamlfind ocamlc" and
native by "ocamlfind ocamlopt".
So, let's come to the question of Sven:
> > What about the requires file ? Should it not list lablgl here ? what about
> > lablgnome.cma, lablgtkgl.cma and lablglade.cma also present in the lablgtk
> > package ?
I have written the META file and I don't need lablgtkgl, lablglgnome and
lablglade. So I have not put them in the archive entry. Now, putting all
of them in the two entries above should not be a mistake, because a .cma
is actually linked if and only if at least one function exported by the
.cma is used. Another solution, instead, is creating new archive() entries
like this one:
archive(byte,gl)="lablgtk.cma lablgtkgl.cma gtkInit.cmo"
If only .cma are missing, then the first solution is easier and less
cumbersome. Instead, if also .cmo files are involved, we have to use
the second solution. Now, I think that gtkThInit.cmo is the .cmo that
causes problems, no? So we can duplicate the archive() entries with
a new thread label.
To sum up, here it is my proposal (untested: is the order of inclusion
of the cma correct?):
archive(byte)="lablgtkgl.cma lablgtk.cma lablgnome.cma gtkInit.cmo"
archive(byte,thread)="lablgtkgl.cma lablgtk.cma lablgnome.cma gtkThInit.cmo"
archive(native)="lablgtkgl.cmxa lablgtk.cmxa lablgnome.cmxa gtkInit.cmo"
archive(native,thread)="lablgtkgl.cmxa lablgtk.cmxa lablgnome.cmxa gtkThInit.cmx"
> If using these archives requires the linking with lablgl we have to
> write a META file for lablgl (remember that requires list _findlib_
> modules) and add "lablgl" to the "requires" list
True. [Now, if you want to use lablgl, you cannot use findlib alone. You
can always write your makefile and benefit from findlib, but with
more work.]
> * the first .deb that will be installed have to install the META file
> putting only "archive(byte)" or "archive(native)" depending on its
> kinf; the second one must only patch the META file adding its
> "archive" line
> * we have version problem, e.g. we can't install bytecode version 2.3
> and nativecode version 4.1 because META file only support one
> version line per package
> Or, last solution, we can have both packages install the same META
> file in postinst script installing all needed information, who cares
> if a nativecode package install information for compiling also
> bytecode? We still have version problems (are really problems?)
???? I don't follow you here. If the two packages install directories are
the same, then we are already doomed to version problems because of .mli
and .cmi files that are shared, aren't we?
Happy new year to everyone!
C.S.C.
--
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------
Reply to: