From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 99FFA7EEBF for ; Mon, 3 Aug 2015 07:38:30 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.217.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jordojw@gmail.com designates 209.85.217.178 as permitted sender) identity=mailfrom; client-ip=209.85.217.178; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f178.google.com) identity=helo; client-ip=209.85.217.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-lb0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmAwAF/r5VlLLZVdFbGQGDHzVpBoMdrhKKcIIvhyIHTAEBAQEBARIBAQEBBwsLCR8lC4Q8ER0BGx4DEgMGBzcCJAERAQUBIjWHdgEDEpUajTqCBYEuPjGLP4FsgnmKbwoZJw1XhQABBQ6TOYFDBY1BhDaDAoxMl3wSI4EXEQaCHRyBcx4xgkwBAQE X-IPAS-Result: A0AmAwAF/r5VlLLZVdFbGQGDHzVpBoMdrhKKcIIvhyIHTAEBAQEBARIBAQEBBwsLCR8lC4Q8ER0BGx4DEgMGBzcCJAERAQUBIjWHdgEDEpUajTqCBYEuPjGLP4FsgnmKbwoZJw1XhQABBQ6TOYFDBY1BhDaDAoxMl3wSI4EXEQaCHRyBcx4xgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,599,1432591200"; d="scan'208";a="172469746" Received: from mail-lb0-f178.google.com ([209.85.217.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Aug 2015 07:38:30 +0200 Received: by lbbyj8 with SMTP id yj8so71819675lbb.0 for ; Sun, 02 Aug 2015 22:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gcCwndWlDn2BfpxMfBh9nYToPzm0v2FiJtWx7oP4D4Q=; b=QHfJ1wAmb3dsj/1GvEyrQzXr6vDoY3Zkl6RQFVtO3z+VmRfJ2xywwiacG3JP4H3IoN L4FA1X2zi0GRWbT5No3c350d4OLk1oSEsDlQ1I0rMAVXthUJLnKjztHw7m2BwHGlhp8m gLTilX1jh5AItn3JhAB3lp9d3Hb+2jV6Dszo1bROaYHyiA9jup/K7X4V46ZcbmQSQY3Y T/XChzC2Zs58xFMe905FEcbf7CIbFCEoxLnDTDYnsOk1q2O1JsA0A6QiP8Xzfjjr5jUf wut0N4v2AM+FXPjpsvH8rDCTeMPxKrOm8fNd7qbkB/xKjtQNoWKPbCnASqZ0hbHokRgv ZaSQ== MIME-Version: 1.0 X-Received: by 10.152.37.2 with SMTP id u2mr14865384laj.70.1438580309121; Sun, 02 Aug 2015 22:38:29 -0700 (PDT) Received: by 10.25.18.22 with HTTP; Sun, 2 Aug 2015 22:38:29 -0700 (PDT) Date: Sun, 2 Aug 2015 22:38:29 -0700 Message-ID: From: Jordan W To: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=089e0158b5e24e5ee6051c6194b8 X-Validation-by: jordojw@gmail.com Subject: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild. --089e0158b5e24e5ee6051c6194b8 Content-Type: text/plain; charset=UTF-8 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 --089e0158b5e24e5ee6051c6194b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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, modules inside of mlpacks will not be *n= ative* compiled with their respective -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)

<= br>
With this, both native and byte compilation succeed for the p= revious example.
However, *because* B references A, then if B is = located in another directory within the depOne root, native compilation wil= l 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 the = following items, pointing to the new respective locations of A, B where B s= till 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/de= pOne.cmx", line 1:
Error: Files path/to/depOne/deeperDir/b.c= mx
=C2=A0 =C2=A0 =C2=A0 =C2=A0and path/to/depOne/a.cmx
= =C2=A0 =C2=A0 =C2=A0 =C2=A0make inconsistent assumptions over implementatio= n A
Command exited with code 1.

Can anyone suggest a fix for this?

Th= ank you,
Jordan
--089e0158b5e24e5ee6051c6194b8--