Re: [Caml-list] Dependencies between plugins

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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

Another (more general, less ad-hoc) way to have this semantics would be to
introduce a "default value" for predicates that do not explictly appear in
rules. Under the set of default values D, then a rule depending on
predicates P would be true if the boolean assignment (D,P=true) holds, with
the rightmost boolean assignment shadowing all others. I mean that the rule

  foo(x1,x2,x3) = ...

would be applied whenever x1=true, x2=true, x3=true with an empty default
environment, but with the default (y1=true, x1=false, y2=false) it would
only be applied whenever (y1=true, x1=true, y2=false, x2=true, x3=true).

Then setting "plugin=false" in the default environment (equivalently,
-plugin) would give the expected semantics, I believe. In particular
(thanks to François for his clear re-explanation on April 9) then the rule
archive(native) would not be matched by the query archive(native,plugin).

I can see a use for another default variable (ocaml=true) allowing people
that could want to use ocamlfind for non-ocaml stuff to disable it
explicitly, and then reuse the rule names for their own stuff. (In
ocamlbuild it is useful to be able to talk about compilation problems that
are not about OCaml).

On Mon, Apr 27, 2015 at 11:51 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
wrote:

> 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: Type: text/html, Size: 9158 bytes --]