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 361D37EEBF for ; Tue, 4 Aug 2015 22:40:09 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.215.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jordojw@gmail.com designates 209.85.215.54 as permitted sender) identity=mailfrom; client-ip=209.85.215.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@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-la0-f54.google.com) identity=helo; client-ip=209.85.215.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-la0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AhAgC4IsFVmzbXVdFbg29aDwaDHbklgi+GAQKBNgdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbHQEDAQsGAwILDSoCAiEBAREBBQEcBhMIGod2AQMKCJcpjz+BLj4xiz+BbIJ5i0cKGScNV4RWAQEBAQEFAQEBAQEBARUBBQ6LQYJPgjkHgmmBQwWNQIQ3gwOKZYFrgUeEIow8hWQSI4EXEQaCHRyBcx4xgkwBAQE X-IPAS-Result: A0AhAgC4IsFVmzbXVdFbg29aDwaDHbklgi+GAQKBNgdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbHQEDAQsGAwILDSoCAiEBAREBBQEcBhMIGod2AQMKCJcpjz+BLj4xiz+BbIJ5i0cKGScNV4RWAQEBAQEFAQEBAQEBARUBBQ6LQYJPgjkHgmmBQwWNQIQ3gwOKZYFrgUeEIow8hWQSI4EXEQaCHRyBcx4xgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,611,1432591200"; d="scan'208";a="142031373" Received: from mail-la0-f54.google.com ([209.85.215.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Aug 2015 22:39:42 +0200 Received: by lady2 with SMTP id y2so11522551lad.0 for ; Tue, 04 Aug 2015 13:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z5Kps5JlX6LNAOjEuOjfoIb9YnoIjOBIAi+ieVgENqM=; b=eNDapbVZ4tNhagT+Q0lJ33Sv0Wsf0HZ2UtQVWNUi2r3JuMb538RAZW5qnGo0lHulW+ JWUJ/6ql06VXhNvoN80hQaBQTGzgxynu7O+EgaruFx3Wp0vJmNcX8DDqGcO/aswsO/T4 aJsXFPrpHPViPeb9bB+wDM/gUfqXh9peoKcY2E5K78fCx3CgJ+0cYOB4OuxZbx7vA9Xl zp2AVRP0QEFN9Kgda9bcPJ1tg0EYYT3mXK/I+6DyO477ZaNgTPrwaxhTBMlpL7Dtf+wj CkhZJZxake0+fKbqB5xykmQLt93ry+xjyLElnoyUDaRKuAI4lM8DL2urJARzP/fG71f5 kwvA== MIME-Version: 1.0 X-Received: by 10.112.163.226 with SMTP id yl2mr6271547lbb.100.1438720782084; Tue, 04 Aug 2015 13:39:42 -0700 (PDT) Received: by 10.25.18.22 with HTTP; Tue, 4 Aug 2015 13:39:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 13:39:42 -0700 Message-ID: From: Jordan W To: Ashish Agarwal Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=089e0115fffa25b020051c8249aa X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild. --089e0115fffa25b020051c8249aa Content-Type: text/plain; charset=UTF-8 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 >> > > --089e0115fffa25b020051c8249aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please do share, if you don't mind (a github gist woul= d be nice so others can see it).

On Mon, Aug 3, 2015 at 5:57 AM, Ashish Agarwal <a= garwal1975@gmail.com> wrote:
I don't use ocamlbuild, but I've recently been w= riting 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, J= ordan W <jordojw@gmail.com> wrote:
It is well known that there are unresolved issu= es with native compilation of mlpacks.

Consider an mlpac= k 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 "hi"
Where depOne/b.ml contains
=C2=A0 =C2=A0 let foo =3D = A.foo

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

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


With this, bot= h native and byte compilation succeed for the previous example.
H= owever, *because* B references A, then if B is located in another directory= within the depOne root, native compilation will once again fail, even thou= gh byte compilation succeeds - even with all of the special hacks that have= been suggested (_tags etc).

For example:=C2=A0
Cons= ider 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 b= efore.

depOne/A
depOne/deeper/B

I= n 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/de= eperDir/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 im= plementation A
Command exited with code 1.


Can anyone suggest a fix for this?

Thank you,
Jordan


--089e0115fffa25b020051c8249aa--