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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id AB80E7EEBF for ; Wed, 5 Aug 2015 07:01:36 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.175 as permitted sender) identity=mailfrom; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f175.google.com) identity=helo; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEAQAlmMFVm6/VVdFbgzo1aQa/BoYBAoE8B0wBAQEBAQESAQEBAQEGCwsJIS6EJAEBBBIRHQEbHQEDDAYFCw0CAiYCAiEBAREBBQEcBhMIGod2AQMSpgiBLj4xiz+BbIJ5i08KGScNV4RWAQEBAQYBAQEBGAEFDoEUii2CT4I5B4JpgUMBBIxOiC+KaYFrki+FZBIjgRcXgh0cgVU8MYJMAQEB X-IPAS-Result: A0AEAQAlmMFVm6/VVdFbgzo1aQa/BoYBAoE8B0wBAQEBAQESAQEBAQEGCwsJIS6EJAEBBBIRHQEbHQEDDAYFCw0CAiYCAiEBAREBBQEcBhMIGod2AQMSpgiBLj4xiz+BbIJ5i08KGScNV4RWAQEBAQYBAQEBGAEFDoEUii2CT4I5B4JpgUMBBIxOiC+KaYFrki+FZBIjgRcXgh0cgVU8MYJMAQEB X-IronPort-AV: E=Sophos;i="5.15,614,1432591200"; d="scan'208";a="172698973" Received: from mail-ig0-f175.google.com ([209.85.213.175]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Aug 2015 07:01:35 +0200 Received: by igbij6 with SMTP id ij6so88165244igb.1 for ; Tue, 04 Aug 2015 22:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GgbfEIt4yeBfsH9OonEiMSK8TgNQC4mlIQ8URuwyyE0=; b=wALTKK1MNYqGPB7PcdIIrCPULYh+c8HbDZrWaz4YuQ2nSCq8/ehxykmXvaLxz07LJe eUZs9DXD8gMreGvD1VCmW9ERDARh8f+xeHfhkh1JQCiLTGY4ISobTW/FDclzDViWztb7 AQoT5oiQOpPWTpK4mZTH9CZpWovNQnuuXFaONuGCFgzWqFoib/M08YHJfjoCt+QskZs9 45t2OKVPBJE6X1OzjJQVlq4RHMUxnN49KeuSDTtZ+AwufLNeKad367OREYzVsmENjiCl SO4tMdRP74BFU+bForcLUmEe2iKFq88Zs77ePBotc8fyZG7rcLLNWAucBH6rYcqflbpQ ONRg== X-Received: by 10.50.128.169 with SMTP id np9mr3814519igb.37.1438750894528; Tue, 04 Aug 2015 22:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Tue, 4 Aug 2015 22:00:55 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Wed, 5 Aug 2015 07:00:55 +0200 Message-ID: To: Jordan W Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild. The fact that native packing requires -for-pack is not a bug of ocamlbuild. The tool mirrors a design choice of the compiler itself, where native and bytecode packing behave differently for technical reasons (native compiled objects cannot be portably renamed, so their final-destination name must be given from the start). I am able to reproduce the issue, but it fails in both bytecode and native, and a workaround (that is not usable in any case) it to add "path/to/depOne" to the list of included directories of the build, by invoking with (ocamlbuild -I path/to/depthOne) or having ("path/to/depthOne": include) in _tags. On Mon, Aug 3, 2015 at 7:38 AM, Jordan W wrote: > It is well known that there are unresolved issues with native compilation of > mlpacks. > > Consider an mlpack that successfully byte code compiles: > > path/to/depOne.mlpack consisting of: > > depOne/A > depOne/B > > Where depOne/a.ml contains > let foo = "hi" > Where depOne/b.ml contains > let foo = A.foo > > While this byte code compiles without issue, modules inside of mlpacks will > not be *native* compiled with their respective -for-pack X. To correct this, > it has been suggested that a _tags file be created with the following: > > : for-pack(DepOne) > > > With this, both native and byte compilation succeed for the previous > example. > However, *because* B references A, then if B is located in another directory > within the depOne root, native compilation will once again fail, even though > byte compilation succeeds - even with all of the special hacks that have > been suggested (_tags etc). > > For example: > Consider if path/to/depOne.mlpack consisted of the following items, pointing > to the new respective locations of A, B where B still refers to A as it did > before. > > depOne/A > depOne/deeper/B > > In this case, native compilation fails, and byte compilation succeeds. > > The errors that I see are: > > File "path/to/depOne.cmx", line 1: > Error: Files path/to/depOne/deeperDir/b.cmx > and path/to/depOne/a.cmx > make inconsistent assumptions over implementation A > Command exited with code 1. > > > Can anyone suggest a fix for this? > > Thank you, > Jordan