From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 39C017EEBF for ; Mon, 3 Aug 2015 14:58:02 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=209.85.212.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of agarwal1975@gmail.com designates 209.85.212.179 as permitted sender) identity=mailfrom; client-ip=209.85.212.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f179.google.com) identity=helo; client-ip=209.85.212.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-wi0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTAQCyZL9VlLPUVdFbGQEBAYMdNWkGgx25A4IvhgECgSEHTAEBAQEBARIBAQEBBwsLCR8whCQBAQECARIRHQEbHQEDAQsGAwIEBzcCAiEBAREBBQEcBhMih3YBAwoIlwuPP4EuPjGLP4FsgnmKdAoZJw1XhFoBAQEBBgEBAQEBARYBBQ6LQYJPgjkHgmmBQwWRd4J8BophgWuSGYVjEiOBFxEGgh0cgW8iMYJMAQEB X-IPAS-Result: A0CTAQCyZL9VlLPUVdFbGQEBAYMdNWkGgx25A4IvhgECgSEHTAEBAQEBARIBAQEBBwsLCR8whCQBAQECARIRHQEbHQEDAQsGAwIEBzcCAiEBAREBBQEcBhMih3YBAwoIlwuPP4EuPjGLP4FsgnmKdAoZJw1XhFoBAQEBBgEBAQEBARYBBQ6LQYJPgjkHgmmBQwWRd4J8BophgWuSGYVjEiOBFxEGgh0cgW8iMYJMAQEB X-IronPort-AV: E=Sophos;i="5.15,601,1432591200"; d="scan'208";a="141905520" Received: from mail-wi0-f179.google.com ([209.85.212.179]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Aug 2015 14:58:01 +0200 Received: by wibud3 with SMTP id ud3so134972616wib.1 for ; Mon, 03 Aug 2015 05:58:01 -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=iuzybLCG21V41TID/cyxIHwas/tEfDRIQNwg+63Xxno=; b=oPltm+mOlu5QZEUezBN1jzDVQPc5e7US0Ft01lviG4DOjUtpxmaQbwQGRbvnBZdc29 QqyIqEzx4wfGsQiJbvMFGCDdkF1YD0Y/5mxNQ/GHXeiIYp6foDi3bEoHocKOQoE18qav 6IiDiNb1ceGGTsochnSFoCOJyCzbycLlDdEMIbGPubxVe3QB/4QQscbtIzHAKQxYedMk k+ksP/ybjBmjFSha5MEzdNxX2q2oqkCQ2tPb5dWOgGzkIFA2eSLLXhkhB5v6bN4U8xTH 0rzL+HLmNC8o6dBpsX6w6GnOLj5YlqKc3vGwgorpwNjs82s3SX8voyq6rebbdwKCdlAg bKcA== X-Received: by 10.180.86.163 with SMTP id q3mr33910945wiz.75.1438606681233; Mon, 03 Aug 2015 05:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.82.86 with HTTP; Mon, 3 Aug 2015 05:57:41 -0700 (PDT) In-Reply-To: References: From: Ashish Agarwal Date: Mon, 3 Aug 2015 08:57:41 -0400 Message-ID: To: Jordan W Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=bcaec50fe34134e37a051c67b8e7 Subject: Re: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild. --bcaec50fe34134e37a051c67b8e7 Content-Type: text/plain; charset=UTF-8 I don't use ocamlbuild, but I've recently been writing an OMake function to support packs. I can send it to you if you're interested. (AFAICT, the OCamlPackage function distributed with OMake is broken.) And FYI, probably the reason for problems only with native packs, is that -for-pack is a noop for bytecode packs. On Mon, Aug 3, 2015 at 1: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 > --bcaec50fe34134e37a051c67b8e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't use ocamlbuild, but I've recently been wri= ting an OMake function to support packs. I can send it to you if you're= interested. (AFAICT, the OCamlPackage function distributed with OMake is b= roken.)

And FYI, probably the reason for problems only w= ith native packs, is that -for-pack is a noop for bytecode packs.


= On Mon, Aug 3, 2015 at 1:38 AM, Jordan W <jordojw@gmail.com>= wrote:
It is well known= that there are unresolved issues with native compilation of mlpacks.
<= br>
Consider an mlpack that successfully byte code compiles:

path/to/depOne.mlpack consisting of:
depOne/A
depOne/B

Where depOne/a.ml contains
=
=C2=A0 =C2=A0 let foo =3D A.foo

While t= his byte code compiles without issue, modules inside of mlpacks will not be= *native* compiled with their respective -for-pack X. To correct this, it h= as been suggested that a _tags file be created with the following:

<= div><path/to/depOne/**/*.cmx>: for-pack(DepOne)


With this, both native and byte compilation succeed for th= e 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:=C2=A0
Consider if path/to/depOne.mlpack consisted of t= he following items, pointing to the new respective locations of A, B where = B still refers to A as it did before.

depOne/A
depO= ne/deeper/B

In this case, native compilation fails, and b= yte compilation succeeds.

The errors that I = see are:

File "path/to/depOne.cmx", line 1:
Error: Files path/to/depOne/deeperDir/b.cmx
=C2=A0 =C2=A0 =C2=A0= =C2=A0and path/to/depOne/a.cmx
=C2=A0 =C2=A0 =C2=A0 =C2=A0make i= nconsistent assumptions over implementation A
Command exited with= code 1.


Can anyone suggest a= fix for this?

Thank you,
Jordan

--bcaec50fe34134e37a051c67b8e7--