Re: lablgtk META with thread and the hell :)
On Thu, Jan 23, 2003 at 02:38:55PM +0100, Stefano Zacchiroli wrote:
> On Thu, Jan 23, 2003 at 11:07:00AM +0100, Sven Luther wrote:
> > about the lablgtkgl predicate ...
>
> I know nothing about lablgtkgl, but I suppose you can easily deduce how
> to add it to the META file ...
Well lablgtkgl is just a binding for gtkglarea, it needs lablgl and
lablgtk.
So basically, independently of the other predicates, it goes like that :
archive(bytecode,gtkgl)="lablgl.cma lablgtk.cma lablgtkgl.cma"
Knowing that lablgtk.cma is in the +lablGL package, and can be used with
togl.cma also.
> > I have just checked also lablgl, and it seems that there is no META file
> > for it also.
>
> Right, I can write it if you tell me what are the 'crucial' ocaml
> objects because I've never used lablgl.
Yes, please, since i don't use findlib, i have no way to check it.
Basically, lablgl has 2 libraries, lablgl.cma and togl.cma.
If you use lablgl alone (with ocamlsdl maybe, or with ocamlGLUT or
whatever), then you just need lablgl. If you use lablgl with the tcl/tk
bindings togl.cma, then you need togl.cma in addition to lablgl.cma.
Now, the difficult part, if you use lablgl with lablgtkgl, you need
lablgl, lablgtk and lablgtkgl, which are found in directory +lablgtk and
+lablGL.
> > also adding a gtkgl predicate to the lablgtk META file would double its
> > size again, right ? This is not very nice, i wish findlib would have a
> > better way of handling this.
>
> The problem isn't as easy as is seems.
> Actually you should have an ordered list of all ocaml objects needed to
> be linked in at compile time for each possible combination of
> predicates.
> An alternative approach could be the one in which each predicate declare
> which object it needs to be linked in _BUT_ with this approach you loose
> the ordering between objects belonging to different predicates.
> If you have a good proposal I think that Gerd will be happy to discuss
> it.
Mmm, the ordering you speak is about linking order ? Is it really needed
to order these ? i guess yes.
Anyway, what about doing this the other way around, having a listing of
all objects/file/archives/whatever, and for each one, the predicates
they support. The ordering would be for the natural ordering of them,
take for example (using lablgtk, lablgl, togl and lablgtkgl as
examples).
lablgl.cma in "+lablGL" : bytecode lablgl togl gtkgl
lablgtk.cma in "+lablgtk" : bytecode init thread gtkgl
togl.cma in "+lablGL" : bytecode togl
lablgtkgl.cma in "+lablgtk" : bytecode thread gtkgl
Then ocamlfind can traverse this file, and build its database the other
way around, resulting in :
if you build with gtkgl and bytecode, you will get lablgl.cma,
lablgtk.cma and lablgtkgl.cma. Mmm, this does not work, because of the
bytecode/nativecode problem, and maybe the thread predicate does not
belong here. It would be like that :
bytecode lablgl.cma in "+lablGL" : lablgl togl gtkgl
bytecode lablgtk.cma in "+lablgtk" : lablgtk gtkgl
bytecode togl.cma in "+lablGL" : togl
bytecode lablgtkgl.cma in "+lablgtk" : gtkgl
This one is better. But it need to be checked for the other files.
> Anyway remember that a META file isn't seen by the final user, it's
> written once by the upstream author or the maintainter it's size is not
> so painful IMO.
Well, but it is in O(2^n), which is not nice, imagine writing a meta
file for a package with 10 libraries ? with 20 ?
> > So i was thinking about adding the gtkgl predicate to lablgl's META file
> > instead, it would go like this :
>
> Ok for me, _you_ are the maintainer :-)
But i never ever use findlib.
> > But then, we need to include both +lablGL and +lablgtk as directories in
> > the last case, is this possible, with maybe :
> >
> > directory(byte,gtkgl)="+lablGL +lablgtk"
>
> No, the "directory" directive simply tell findlib where the object
> listed in metafile reside and predicates are ignored for that directory.
> If you have META files belonging to different directory is better to
> have a META file for each directory and use the "requires" findlib
> directive to declare dependencies between packages.
So, you should only put libraries in one file that reside in the same
directory, i like my proposal better, since the location can be found on
a per library basis.
Friendly,
Sven Luther
Reply to: