[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic dependencies for shared modules



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 <glondu@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


Reply to: