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 <agarwal1975@gmail.com> 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 <jordojw@gmail.com> 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:

<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 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