Re: [Caml-list] Dependencies between plugins

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

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

Well, I was quickly thinking about this obvious alternative, but I think
it is even a more ad-hoc solution. We are changing the rules until they
are matching the META files... Defaults have the disadvantage that they
are somewhat invisible to the user, and make it harder to understand
what's actually going on.

I have another idea. Maybe the wrong starting point of all previous
suggestions is to reuse the "archive" variable for plugins. We could
also have a separate variable for this, e.g. "plugin":

archive(byte) = "file.cma"
archive(native) = "file.cmxa"
plugin(byte) = "file.cma"
plugin(native) = "file.cmxs"

This is even a bit simpler than my previous suggestion. We would need a
little bit of magic for a transition phase, but I think this could be
somewhat more attractive in the long term.

Am Montag, den 27.04.2015, 12:16 +0200 schrieb Gabriel Scherer:
> 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.
> ...
> 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).

Basically you can already do that if you avoid the variables that are
used for ocaml. E.g. you have a script language "dofoo" and want to
manage deps with ocamlfind. You would just not reuse "archive", but a
different variable, let's say dofoo_script. There is already quite good
support for such alternate variables, e.g.

ocamlfind query -format '%+(dofoo_script)' -recursive pkg...

would print all such script names (with absolute path) of pkg, including
the predecessors.

Gerd



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

-- 
------------------------------------------------------------
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 --]