Hi again! So the plugins are working in nativecode and I have worked around dh_ocaml by not calling. However, things get more messy in bytecode mode..
First, some comments on your previous reponse: 2011/5/24 Stéphane Glondu <glo...@debian.org>: > Le 24/05/2011 16:31, Romain Beauxis a écrit : >> >> Hmm.. You mean build a cmxs for sdl at build-time? First, this would >> give the same error and it would also increase the complexity of the >> dynamic loading, in order to resolve dependencies etc.. > > I meant building sdl.cmxs in ocaml-sdl package. It's quite easy and can be > done in debian/rules. Have a look at postgresql-ocaml, for example. Then the > META, *.cmxs and *.cma should be moved to the runtime package. dh_ocaml > should then infer the right dependencies. I think this highly impractical. We'd have to implement the whole dependency resolving in order to load the modules in the right order in the application.. Clearly not an option! >> Unfortunately, I would need to use dh_ocaml at least for bytecode >> modules, to get the right dependency against the corresponding >> implementation.. > > You said in your original e-mail that you didn't want any ocaml > dependencies. Did you try the --nodefined-map command-line option of > dh_ocaml, then? That does not work for bytecode modules. For instance, the vorbis module include Vorbis and I do want to therefore get a dependency on the right libvorbis-ocaml-xxyyzz.. >> All in all, I still do not understand your point. What is wrong with a >> plugin containing module Foo and being the only one loading this unit >> in the whole program? > > What do you do when someone else wants to make a plugin that can be > concurrently loaded and depends on Foo? You seem to forbid that in your > specific case, but it can happen in general. In this case (a plugin), this is an upstream bug and should not be our issue. All in all, I think that currently, dynamic modules are treated as is they where regular OCaml modules. However, this does not work for application plugins, which we also should support. Therefore, I propose to include an option in dh_ocaml that would allow to accept to reference modules that are present in a plugin and are also provided by another package. This should of course be opt-in. I am ok to investigate the patch. Romain -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinw00o+v111o7ygjubuvwo4-yg...@mail.gmail.com