Unfortunately, this approach does not support the case where only some libraries are built and installed. Generally, I don't think it's a good idea to depend only on lablgtk if you are also using some extension libraries. The lablgtk2 script loads all available libraries, but I see this as a special case.
Jacques 2012/09/11 23:04 "William" <r...@libertysurf.fr>: > Hello, > > To conclude on this, would it be possible to make this META file instead > of the one proposed in 2.16.0 : > > > > ** META file ** > > description = "Bindings for gtk2" > requires = "" > version = "2.16.0" > * > requires = "lablgtk2.base lablgtk2.gl lablgtk2.glade lablgtk2.gnomecanvas > lablgtk2.gnomehtml lablgtk2.gnomeui lablgtk2.gtkspell lablgtk2.panel > lablgtk2.rsvg lablgtk2.sourceview lablgtk2.sourceview2"* > * > package "base" (* > archive(byte) = "lablgtk.cma" > archive(native) = "lablgtk.cmxa" > archive(byte,mt) += "gtkThread.cmo" > archive(native,mt) += "gtkThread.cmx" > *)* > package "auto-init" ( > exists_if = "gtkInit.cmo,gtkInit.cmx" > description = "Auto-initialization of GTK" > requires = "lablgtk2.base" > archive(byte) = "gtkInit.cmo" > archive(native) = "gtkInit.cmx" > ) > package "gl" ( > exists_if = "lablgtkgl.cma,lablgtkgl.cmxa,lablgtkgl.cmxs" > description = "Bindings for gtkGL" > requires = "lablgtk2.base" > archive(byte) = "lablgtkgl.cma" > archive(native) = "lablgtkgl.cmxa" > ) > package "glade" ( > exists_if = "lablglade.cma,lablglade.cmxa,lablglade.cmxs" > description = "Bindings for glade" > requires = "lablgtk2.base" > archive(byte) = "lablglade.cma" > archive(native) = "lablglade.cmxa" > ) > package "gnomecanvas" ( > exists_if = > "lablgnomecanvas.cma,lablgnomecanvas.cmxa,lablgnomecanvas.cmxs" > description = "Bindings for gnomecanvas" > requires = "lablgtk2.base" > archive(byte) = "lablgnomecanvas.cma" > archive(native) = "lablgnomecanvas.cmxa" > ) > package "gnomehtml" ( > exists_if = "lablgnome.cma,lablgnome.cmxa,lablgnome.cmxs" > description = "Bindings for gnome html" > requires = "lablgtk2.base" > archive(byte) = "lablgnome.cma" > archive(native) = "lablgnome.cmxa" > ) > package "gnomeui" ( > exists_if = "lablgnomeui.cma,lablgnomeui.cmxa,lablgnomeui.cmxs" > description = "Bindings for gnomeui" > requires = "lablgtk2.base" > archive(byte) = "lablgnomeui.cma" > archive(native) = "lablgnomeui.cmxa" > ) > package "gtkspell" ( > exists_if = "lablgtkspell.cma,lablgtkspell.cmxa,lablgtkspell.cmxs" > description = "Bindings for gtkspell" > requires = "lablgtk2.base" > archive(byte) = "lablgtkspell.cma" > archive(native) = "lablgtkspell.cmxa" > ) > package "panel" ( > exists_if = "lablpanel.cma,lablpanel.cmxa,lablpanel.cmxs" > description = "Bindings for panelapplet" > requires = "lablgtk2.base" > archive(byte) = "lablpanel.cma" > archive(native) = "lablpanel.cmxa" > ) > package "rsvg" ( > exists_if = "lablrsvg.cma,lablrsvg.cmxa,lablrsvg.cmxs" > description = "Bindings for rsvg" > requires = "lablgtk2.base" > archive(byte) = "lablrsvg.cma" > archive(native) = "lablrsvg.cmxa" > ) > package "sourceview" ( > exists_if = > "lablgtksourceview.cma,lablgtksourceview.cmxa,lablgtksourceview.cmxs" > description = "Bindings for gtksourceview" > requires = "lablgtk2.base" > archive(byte) = "lablgtksourceview.cma" > archive(native) = "lablgtksourceview.cmxa" > ) > package "sourceview2" ( > exists_if = > "lablgtksourceview2.cma,lablgtksourceview2.cmxa,lablgtksourceview2.cmxs" > description = "Bindings for gtksourceview2" > requires = "lablgtk2.base" > archive(byte) = "lablgtksourceview2.cma" > archive(native) = "lablgtksourceview2.cmxa" > ) > > ** end of META file ** > > > with those modifications : > > - it is possible to compile "easily" any software that uses lablgtk2 code: > ocamlfind opt -package lablgtk2 -linkpkg test.ml > > - it is possible to optimise the build process, by choosing exactly what > we need (with a little more knowledge of lablgtk2) : > ocamlfind opt -package lablgtk2.gtkgl lablgtk2.gnomeui -linkpkg test.ml > > > This method is usable both for the novice and for the expert. It is > similar to the one used by camlimages, but here the "default" is to include > as much as possible. > > > Best regards, > William > > On 08/28/2012 08:39 AM, Adrien wrote: > > Hi, > > I don't have much time to answer so I'll make my best and not forget anything. > > On 28/08/2012, Syndic Copropriété 4 rue Pasteur <sdc4past...@yahoo.fr> > <sdc4past...@yahoo.fr> wrote: > > Hello, > > As I saw the new META file for lablgtk2, many questions and issues rose. > It concerns both lablgtk2 and the way ocamlfind is implemented. It may > be also interesting for packagers (in godi for example) who design META > files. > > - lablgtk2 defines 10 sub packages plus package "auto-init" (for which > one must be able to chose to include it or not). When users add a > dependency to a project, it is far easier at first to only add the name > of the package (here "lablgtk2") without trying to understand what is > exactly behing. It would be easier for users to have : > * package "lablgtk2" that includes everything but gtkInit.cmo > and gtkInit.cmx, > * package "lablgtk2.auto-init" that includes "gtkInit.cmo and > gtkInit.cmx" and package "lablgtk2" (gtkInit is special because it > includes code that sometime you want to use, and sometime not). > > First, a small note about the "auto-init" subpackage: the > functionality was first made for the toplevel, and it can be nice and > handy for compiled programs too (which is why it is exposed in this > META) but don't abuse it. > For instance, the META in godi used to always pull GtkInit. In turn, > that tried to init, well, GTK+. That required running under X. Having > to start an X server simply to build lablgtk2 was a bit annoying. > > Also, this META file was made for another reason: avoiding that > everything always gets linked in. The issue is not that it pulls more > OCaml modules: the _big_ issue is that it pulls C libraries too. For > the packages I have on this machine, that would mean you'd need gl, > glade, gnomecanvas, gnomeui (so many more gnome components most of the > time), gtkspell, rsvg, sourceview2. That also makes binary > distribution harder. > > There has also been issues with GL support (not because of lablgtk2, > but because of the underlying C libs which aren't always available) so > it's better to make it possible to chose. > > I considered also making a big meta-package with all the subpackages > but then, people would have been unhappy because it would have had one > more dep than they wanted and I would have had to make meta-packages > with n-1 subpackages. And so on. :-) I thought there would be no > solution that pleased everyone. > > > - Is that a problem to include in an ocamlfind package (through variable > "require") an archive (cma, cmx, cmxs) that is not used after ? > > It's not an issue. Most of the time, the module should even be > unlinked in the final executable (watch out if you're using dynlink). > > > - does including all available packages through variable "require" make > an executable that takes more space ? If yes, could ocamlfind handle > this so that it does not include unused packages? > > Yes and no. And it's ocaml which already handles that. It also depends > on how things are done in the library and its META file. I haven't > checked how it behaved in lablgtk2 but if there are reports, I'd be > interested in them. > > > - if the purpose of making many packages is only to see what is > available through ocamlfind query, maybe it would be interesting that > ocamlfind query lists all available files associated to a package? > > Which files do you mean? .cmxa files for instance? If so, ocamlfind > query can already do that; the syntax is a bit hard to get right > however (proof: I'm not even going to try to give it right now). > > > - If find this line rather strange : exists_if = > "lablgtkgl.cma,lablgtkgl.cmxa,lablgtkgl.cmxs" > * lablgtkgl.cma and lablgtkgl.cmxa are part of the variable > "archive", so what is the point in having it there too ? > * lablgtkgl.cmxs enables package "gl", but is not used in any > variable "require" > > The documentation for exists_if states that the subpackage will exist > if any of the files given exists so the goal look correct to me. > However, I don't know if "exists_if" implicitely includes "archive" (I > don't think so). > > > - It seems ocamlfind lacks two clear variables that are actually > undertaken by exists_if and requires : > * variable "depends" (actually, "exists_if" and "requires") that > tells that this package can only work if the specified sub packages are > here. If not, package would be disabled. (e.g "lablgtk2.auto-init" that > depends on "lablgtk2"). > > With "lablgtk2" being the main-package, "lablgtk2.auto-init" already > requires "lablgtk2". You can try using "ocamlfind ocamlopt -package > lablgtk2.auto-init ...", it should just work(tm). > > > * variable "includes" (actually "requires", roughly) that includes > other packages, if available, so that the user do not need to also > specify them (e.g : "lablgtk2" would include "lablgtk2.glade", > "lablgtk2.gl" if they are here) > > As I've stated earlier, that's something I quite opposed to because it > would require far too many things or it would change from one > configuration to another (through the exists_if mechanism). > > > - it would be nice that ocamlfind gives examples such as the lablgtk2 > one, to show how to design a good META file. > > The META(5) documentation is pretty good but I have to agreee that it > lacks an example. This lablgtk2 META file has been made after reading > several other META files, most notably Debian's for lablgtk2, and > lwt's. Having pointers to existing good files in the documentation > would be nice. > > Btw, this META file tries to provide a pretty good compatibility with > the one in Debian, the on in godi and the old upstream one (which > includes Fedora). It is going to require some updating but it should > be trivial and there shouldn't be anything to fear in migrating. :-) > > Regards, > Adrien Nader > > > > > > _______________________________________________ > Godi-list mailing list > Godi-list@ocaml-programming.de > https://godirepo.camlcity.org/mailman/listinfo/godi-list >
_______________________________________________ Godi-list mailing list Godi-list@ocaml-programming.de https://godirepo.camlcity.org/mailman/listinfo/godi-list
