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 2A2DC7EEBF for ; Tue, 4 Aug 2015 23:19:21 +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.180; 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.180 as permitted sender) identity=mailfrom; client-ip=209.85.212.180; 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-f180.google.com) identity=helo; client-ip=209.85.212.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-wi0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAgD/KsFVlLTUVdFbg29pBoMduSaCN4V5AoE3B0wBAQEBAQESAQEBAQcLCwkfMIQjAQEBAwESER0BGx0BAwELBgMCCw0qAgIhAQERAQUBHAYTIod2AQMKCA2WfY8/gS4+MYs/gWyCeYtLChknDVeEVgEBAQEBBQEBAQEBAQEBFAEFDotBgk+CNQQHgmmBQwWRd4J9BoR9hWiBa4FHhCKMPIVkEiOBFxEGgh0cgW8iMYJMAQEB X-IPAS-Result: A0CIAgD/KsFVlLTUVdFbg29pBoMduSaCN4V5AoE3B0wBAQEBAQESAQEBAQcLCwkfMIQjAQEBAwESER0BGx0BAwELBgMCCw0qAgIhAQERAQUBHAYTIod2AQMKCA2WfY8/gS4+MYs/gWyCeYtLChknDVeEVgEBAQEBBQEBAQEBAQEBFAEFDotBgk+CNQQHgmmBQwWRd4J9BoR9hWiBa4FHhCKMPIVkEiOBFxEGgh0cgW8iMYJMAQEB X-IronPort-AV: E=Sophos;i="5.15,611,1432591200"; d="scan'208";a="142032992" Received: from mail-wi0-f180.google.com ([209.85.212.180]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Aug 2015 23:19:20 +0200 Received: by wibud3 with SMTP id ud3so40313690wib.0 for ; Tue, 04 Aug 2015 14:19:19 -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=58m6/XpK9jFugs7UWi/qYgKIts8rP5EOrBZpL361SU8=; b=WHdNdQ8mv/ZTphA5wx9dSJhfCXBUOnVBpcQBl0v/H/hGEtofSyO24+jr6oMt7VKfVU KfOg4Gu9NU6F7ZPQWOHkNMKcrRs4DyMx+rlFlG6mFAN6OBx1WeOZGZg4CGjwACjuHIHi Kr5EPoP8vqZ3kc6ZWvbkfF/6PYF5i9xkcNLXGkSpgXMn1w1Io6097fiIo5SKrWRbScej GamCHnOgy6iP1pamuOGT5GSZaxSYaXDz3lqP21sGsHotx7RgYO4NVB2npW2ugod62r/R 1Osc7lnU9SFLJgiPkaropqH2fHQbBN6n3D0OWIjyJDDLy4lBE0IUUvDHUjfLi7Wr6C3q invg== X-Received: by 10.181.13.230 with SMTP id fb6mr11471197wid.47.1438723159890; Tue, 04 Aug 2015 14:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.82.86 with HTTP; Tue, 4 Aug 2015 14:19:00 -0700 (PDT) In-Reply-To: References: From: Ashish Agarwal Date: Tue, 4 Aug 2015 17:19:00 -0400 Message-ID: To: Jordan W Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=f46d043c05bce02164051c82d653 Subject: Re: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild. --f46d043c05bce02164051c82d653 Content-Type: text/plain; charset=UTF-8 Warning: the code isn't very good, but I'm posting since you asked for it: https://gist.github.com/agarwal/c75e56b200050343fdbb On Tue, Aug 4, 2015 at 4:39 PM, Jordan W wrote: > Please do share, if you don't mind (a github gist would be nice so others > can see it). > > On Mon, Aug 3, 2015 at 5:57 AM, Ashish Agarwal > wrote: > >> 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 >>> >> >> > --f46d043c05bce02164051c82d653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Warning: the code isn't very good, but I'm po= sting since you asked for it:
https://gist.github.com/agarwal/c75e56b200050343fd= bb


On Tue, Aug 4, 2015 at 4:39 PM, Jordan W &l= t;jordojw@gmail.com<= /a>> wrote:
Pl= ease do share, if you don't mind (a github gist would be nice so others= can see it).

On Mon, Aug 3, 2015 at 5:57 AM, A= shish Agarwal <agarwal1975@gmail.com> wrote:
I don't use ocamlbuild, but I&#= 39;ve recently been writing an OMake function to support packs. I can send = it to you if you're interested. (AFAICT, the OCamlPackage function dist= ributed with OMake is broken.)

And FYI, probably the rea= son for problems only with native packs, is that -for-pack is a noop for by= tecode packs.


On Mon, Aug 3, 2015 at 1:38 AM, Jordan W <= span dir=3D"ltr"><jordojw@gmail.com> wrote:
=
It is well known that there are unresolved issues with nat= ive compilation of mlpacks.

Consider an mlpack that succ= essfully byte code compiles:

path/to/depOne.m= lpack consisting of:

depOne/A
depOn= e/B

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

While this byte code compiles without issue, mo= dules 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 c= reated with the following:

<path/to/depOne/**/*.cmx>: 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 t= he depOne root, native compilation will once again fail, even though byte c= ompilation succeeds - even with all of the special hacks that have been sug= gested (_tags etc).

For example:=C2=A0
Consider if p= ath/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 ca= se, 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0and path/to/depOne/a.cmx
=C2=A0 =C2=A0 =C2=A0 =C2=A0make inconsistent assumptions over implementat= ion A
Command exited with code 1.

=
Can anyone suggest a fix for this?

= Thank you,
Jordan



--f46d043c05bce02164051c82d653--