Unable to specify a dynlink plugin build

[pascutto]

Hi!
I am trying to compile a dynlink plugin, and I'mhaving a hard time finding the correct dune rule for it.

My scenario is as follows:

• main executable accepts dynlink plugins. This is out of my repository and I don't own the code.
• lib is a library I own.
• plugin is a plugin for main, it depends on lib and sits in the same repository, but is in a different package.

Because of the issue mentioned here (I need -linkpkg), the rule for building plugin is done by hand, and is currently:

(rule
 (targets plugin.cmxs)
 (action
  (run ocamlfind ocamlopt -shared -linkall -linkpkg -package lib
    %{cmxa:plugin} -o %{targets})))

This works fine compilation-wise.

However, the issue I'm facing is -package lib is specified out of the scope of dune , and therefore is not correctly scheduled. Since they are both in the same repository, dune build fails because lib.cmxa is not built yet at the time this rule is executed.

I tried to fix this in multiple ways, including:

• Adding (deps (package lib)); but that fails when used with -p option with Error: No rule found for alias .lib-files.
• Adding something like (deps ../path/to/lib.cmxa), but besides being awful, it produces an error because lib is both present locally and installed in the opam switch.

How can I properly specify the dependency to lib so it works both locally and in opam? More generally, is there a simpler way to specify the plugin build without writing a custom rule?

[nojb]

Hello, could you try #3141 and see if it solves your problem? You should use a stanza like

(executable
 (name plugin)
 (modes plugin)
 (libraries lib)
 (statically_linked_libraries lib))

(note that the syntax is not final yet and may change)

[pascutto]

Seems to solve it indeed! Thanks!

[nojb]

Seems to solve it indeed! Thanks!

Great, thanks for the quick reply. The PR still needs some polishing, but hopefully will be included in the next release.

[bobot]

Do you tried to link with findlib.dynload? Could you take a look at #3104, it is not polished but I'm currently testing it for rewritting the plugin system for Frama-C and Why3.

[nojb]

#3141 was merged, so I think this can be closed.