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