Re: [Caml-list] Dependencies between plugins

[Gerd Stolpmann <info@gerd-stolpmann.de>]

[-- Attachment #1: Type: text/plain, Size: 5620 bytes --]

François,

I was thinking again about this issue. Introducing a third category
"shared" in addition to byte and native seems to be a bit odd. Actually,
what we really want to have is a second dimension plugin/executable in
addition to the already existing byte/native dimension, so that we can
have:

 - byte + executable (cmo)
 - native + executable (cmx)
 - byte + plugin (cmo, too)
 - native + plugin (cmxs)

That way we can have a separate cmo for byte+plugin, which may be useful
here and there. Also, byte and native are again symmetric.

A typical META file would now specify

archive(byte,executable) = "..."
archive(native,executable) = "..."

if it doesn't support plugins, and specify

archive(byte,executable) = "..."
archive(native,executable) = "..."
archive(byte,plugin) = "..."
archive(native,plugin) = "..."

if it does so. (NB. "executable" because these are the objects for
creating executables.)

The only remaining question is how to handle existing META files that
don't make this distinction. We don't have a version number in META
files, so we have to watch out for another criterion. I am thinking
about understanding

archive(native) = "..."

as

archive(native,executable) = "..."

if there is no other reference to the executable predicate. This would
be a special fixup after parsing META. After a transition phase (say,
two years from now on) we would consider archive(native) as an error.
The upcoming META lint will report this issue.

This way, the existing META files can still be used for some time,
including those specifying plugins. There is no hurry in changing this
detail. However, you are absolutely right that the current use of
"plugin" breaks the way the predicates are defined, and in the long term
this is worth fixing.

Gerd



Am Dienstag, den 14.04.2015, 14:45 +0200 schrieb François Bobot:
> 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
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]