From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 9096E7FCCB for ; Thu, 9 Apr 2015 16:47:30 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of francois.bobot@cea.fr) identity=pra; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="francois.bobot@cea.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of francois.bobot@cea.fr) identity=mailfrom; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="francois.bobot@cea.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@cirse-out.extra.cea.fr) identity=helo; client-ip=132.167.192.142; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="francois.bobot@cea.fr"; x-sender="postmaster@cirse-out.extra.cea.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfAQBgkCZVnI7Ap4Rch0vGKoJcAoE+OxEBAQEBAQEBEQEBAQEBCAsJCRQuhCABAQQjDwEFQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcCiCa3DJZZAQEBAQEFAQEBAQEBARuBIYoKhHwHgmiBRQWiII1KhBODMAEBAQ X-IPAS-Result: A0CfAQBgkCZVnI7Ap4Rch0vGKoJcAoE+OxEBAQEBAQEBEQEBAQEBCAsJCRQuhCABAQQjDwEFQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcCiCa3DJZZAQEBAQEFAQEBAQEBARuBIYoKhHwHgmiBRQWiII1KhBODMAEBAQ X-IronPort-AV: E=Sophos;i="5.11,550,1422918000"; d="scan'208";a="108995311" Received: from cirse-out.extra.cea.fr ([132.167.192.142]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2015 16:47:30 +0200 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t39ElTn8002830; Thu, 9 Apr 2015 16:47:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C79EA209DEE; Thu, 9 Apr 2015 16:48:34 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA061209CB4; Thu, 9 Apr 2015 16:48:34 +0200 (CEST) Received: from [10.8.32.80] (is222783.intra.cea.fr [10.8.32.80]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t39ElSd9023770; Thu, 9 Apr 2015 16:47:28 +0200 Message-ID: <55269100.4000401@cea.fr> Date: Thu, 09 Apr 2015 16:47:28 +0200 From: =?UTF-8?B?RnJhbsOnb2lzIEJvYm90?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Gabriel Scherer CC: OCaml Mailing List References: <552666C5.6070103@cea.fr> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] META file standards for native plugins On 09/04/2015 15:27, Gabriel Scherer wrote: > I don't understand the problem with the current semantics. The .cmxs will be linked when both > predicates "archive" and "plugin" are true, and that seems correct to me (we use this when we want > to link a *plugin* inside a *native* program). This is consistent with the use for example of > (syntax,preprocessor,camlp4o) and (syntax,preprocessor,camlp4r) to select standard or revised > syntax, or (syntax,toploop) when invoked from the toplevel. Also many packages currently use > archive(byte,plugin) as well (which links to the .cma, just as with only archive(byte)). > When two sets predicate are incomparable you don't have the problem. The problem is when one is included in the other. Just to recall, the semantic of ocamlfind define an applicable assignment as : * An assignment can only be used if all positive formal predicates are included in the set of actual predicates, and if all negative formal predi‐ cates are not included in the set of actual predicates. Such an assignment is called applicable. If there is no such assignment, the variable will have no value. When you ask for a set of predicate you want all the applicable assignment to make sense. If you ask for (syntax,preprocessor,camlp4o) you agree to receive the variable associated to (syntax,preprocessor) because it is more general. If you are compiling a multithreaded bytecode program the predicates are (byte, mt, mt_posix,...) you are happy to receive archive(byte). But when you ask (plugin,native) you don't want to receive (native) because cmx can't be used for cmxs, so it should not be applicable. So you should not ask (plugin,native) but something incomparable with (native). Do you agree? For bytecode, when looking for bytecode plugin we can ask for (byte,plugin) because we agree to receive (byte), and it is a good idea to allow people that have a specific version of their library for dynamic linking to define archive(byte,-plugin) and archive(byte,plugin). We can't use (byte,shared) because (shared) is then applicable. -- François