On Tue, 11 Sep 2012 23:03:44 +0200 William <r...@libertysurf.fr> wrote:
> Hello, Hello, > To conclude on this, would it be possible to make this META file instead > of the one proposed in 2.16.0 : I still don't understand the original problem. Here you make the main package require all optional packages. Wouldn't it be a problem when they are not available ? Moreover, counting on the compiler to link only the modules really used, to prevent having big executables, doesn't work any more when the -linkall option is passed, which is quite common for executables handling plugins and still not willing to give access to all gtk modules. I think the current META is good enough. Regards, Maxence > > > ** 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> > > 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 > > > > -- Maxence Guesdon _______________________________________________ Godi-list mailing list Godi-list@ocaml-programming.de https://godirepo.camlcity.org/mailman/listinfo/godi-list
