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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

The fact that native packing requires -for-pack is not a bug of
ocamlbuild. The tool mirrors a design choice of the compiler itself,
where native and bytecode packing behave differently for technical
reasons (native compiled objects cannot be portably renamed, so their
final-destination name must be given from the start).


I am able to reproduce the issue, but it fails in both bytecode and
native, and a workaround (that is not usable in any case) it to add
"path/to/depOne" to the list of included directories of the build, by
invoking with (ocamlbuild -I path/to/depthOne) or having
("path/to/depthOne": include) in _tags.

On Mon, Aug 3, 2015 at 7: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