Re: [Caml-list] Dependencies between plugins

["François Bobot" <francois.bobot@cea.fr>]

On 14/04/2015 11:47, Stéphane Glondu wrote:
> Le 14/04/2015 10:59, François Bobot a écrit :
>>>> Are there any movement in this direction, or this patches will die?
>>>
>>> Don't think so. Slowness on my side.
>>
>> On my side, I haven't yet written the documentation. My main impediment
>> is to choose which predicates to use for the cmxs in the META file:
>> 1) to keep archive(plugin,native) because it is the defacto standard
>> 2) to move to something that is semantically right:
>> archive(native_plugin) or archive(shared).
>
> Sorry, I didn't follow the whole discussion but... this looks like
> hardcoding a special treatment of plugins for the native case,
> forgetting the bytecode case. Would you introduce byte_plugin (or a
> bytecode counterpart to "shared" which looks bad to me) as well?

The fact is that native and bytecode are not symmetric:
              | byte  | native
static link  | cmo   | cmx
dynamic link | cmo   | cmxs

So for bytecode we can still use `archive(byte)`. If someone wants its library to be loaded 
differently in static linking and dynamic linking e can use `archive(byte,plugin)`.

You are right that I should give a full proposal (I'm going to go with `shared` instead of 
`native_plugin` because it is short and correspond to the ocamlopt option):

1. In META file:
   1.1 use `archive(byte)` and `archive(native)` for the files to statically link
   1.2 use `archive(byte,plugin)` for the files to dynamically link in bytecode if they are 
different from the static one
   1.3 use `archive(shared)` for the files that are dynamically linked in native code

2. During dynamic loading:
   2.1. in bytecode: look for variable `archive` with predicates `byte`,`plugin` and the other 
predicates used during compilation (`mt`, `mt_posix`, `mt_vm`, `gprof`, ...)
   2.2  in native: look for variable `archive` with predicates `shared`, `plugin` and the other 
predicates used during static linking except `native`


My goal is just that when you ask in native code "Does this library define files for dynamic 
linking" the answer is not "yes, it defines these cmx". There are other solutions (like asking that 
file to statically link are define with `archive(native,-plugin)`) but they seem to be less 
conservative.

 > Even
 > code using Dynlink should be as generic (w.r.t. native/bytecode) as
 > possible...


The examples of tools that use dependencies between plugins gathered at the start of the discussion 
are already not generic (w.r.t. native/bytecode) :

The following code makes a differences between bytecode and native code:
https://github.com/ocsigen/ocsigenserver/blob/master/src/baselib/ocsigen_loader.ml#L165
https://github.com/zoggy/stog/blob/e83c363c83465a7bfd1595816b3d9bc8331af560/stog_dyn.ml#L119-L146

This one works only for native code, it seems:
https://github.com/hammerlab/ketrew/blob/master/src/lib/pure/ketrew_plugin.ml#L52

The proposed modification is to replace (for example in ocsigen):

```ocaml
(if Ocsigen_config.is_native then "native" else "byte")
```

by

```ocaml
(if Ocsigen_config.is_native then "shared" else "byte")
```

-- 
François