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

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

[Jordan W]

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

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: 2075 bytes --]

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

[Ashish Agarwal]

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

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

[Jordan W]

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

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

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

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

[Ashish Agarwal]

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

Warning: the code isn't very good, but I'm posting since you asked for it:
https://gist.github.com/agarwal/c75e56b200050343fdbb


On Tue, Aug 4, 2015 at 4:39 PM, Jordan W <jordojw@gmail.com> wrote:

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

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

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

[Gabriel Scherer]

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