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 _______________________________________________ Godi-list mailing list Godi-list@ocaml-programming.de https://godirepo.camlcity.org/mailman/listinfo/godi-list
