Re: ocaml-doc patch for /usr/share/doc/ocaml
On Thu, Dec 27, 2001 at 12:25:55AM +0100, Stefano Zacchiroli wrote:
> On Wed, Dec 26, 2001 at 07:31:07PM +0100, Sven wrote:
> > mmm, could you explain this meta file stuff to me a bit more :
> >
> > requires=""
> the _findlib_ packages on which this one depends
>
> > version="1.2.3"
> simple version string, only for documentation purpose
>
> > 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")
>
> > linkopts=""
> special option needed for linking, no longer needed from ocaml 3.00
>
> > directory="+lablgtk"
> directory that will be looked for interfaces and object (adding -I
> switch to the compiler)
>
> > 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 ? What if i splitt thelablgtk package as well as the lablgl one ?
>
> [ Note that the META file I sent was written by Claudio and also that I
> used only a little lablgtk ]
> That said:
> - no, lablgl is not required as a prerequisite for lablgtk. From my
> (even if poor) experience with lablgtk I have never compiled using
> lablgl archives or .cmo, I only used lablgtk.cma gtkInit.cmo and
> lablglade.cma. But I think that the problem may resides in
> lablgtkgl.cma or lablgnome.cma, is this the case?
> 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
> - anyway, yes, we surely have to add lablglade.{cma,cmxa} for users that
> use lablgladecc
> - about the splitting: if you are talking about the splitting of .so
> away this is not a concern of findlib, META file will be put only in
> -dev package and does not care of .so files. If you are talking about
> the splitting of native and bytecode this is more cumbersome. Findlib
> is thinked for package that contains both native and bytecode or, at
> least, is not thinked for different distribution of the twos. We may
> use two different _findlib_ package, but we have to install _two META_
> files in _two different directory_, is pretty trick but avoids
> versions problems. As another solution we may use a common directory
> with only one META file, but:
> * 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?)
>
> Probably we may ask Gerd on this question, I doubt that he had ever
> thinked about findlib interaction with bytecode/nativecode splitting.
>
> Anyway remember that we (almost but not fully) agree that
> native/bytecode splitting _of libraries_ is not that interesting, that
> splitting is really interesting for applications.
Thanks for the explanation.
That said, i was not speaking about the bytecoee/nba tvie code splitting,
but about a splitting of the lablgl and lablgtk packages i have discussed some
time ago (well, not sure that it went trough the list, but i did speak with
Jacques about it).
Basically it goes like this :
split lablgl into :
o lablgl
o lablgk-tk (which contains the togl and labltk support)
split lablgtk into :
o lablgtk
o lablglgtk (or lablgtk-gl or whatever) (which contains the gtkglarea
support of lablgtk)
This would enable us to have a lablgtk package not dependent on lablgl for
htose of you don't wanting to do openGL stuff, and enable people to install
only lablgtk-gl and lablgl, if they don't want to use the tk version of
lablgl.
Friendly,
Sven LUther
Reply to: