[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Sven LUther

Reply to: