Re: [Caml-list] Problem with native compilation of mlpacks in ocamlbuild.

[Ashish Agarwal <agarwal1975@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2805 bytes --]