[m-dev.] "executables" in the java grade

[Julien Fischer]

On Wed, 3 Dec 2014, Paul Bone wrote:

> On Wed, Dec 03, 2014 at 06:55:54PM +1100, Julien Fischer wrote:
>> On Wed, 3 Dec 2014, Paul Bone wrote:
>>
>>> On Wed, Dec 03, 2014 at 03:12:40PM +1100, Julien Fischer wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've recently been experimenting with versions of the Mercury compiler built in
>>>> the java grade.  With a little bit of fiddling about it is possible to get a
>>>> working Mercury compiler that runs on the JVM.  One of the main bit of fiddling
>>>> about is related to how we build "executables" in the java grade.  Currently,
>>>> when we do
>>>>
>>>>     $ mmc --grade java --make foo
>>>>
>>>> we end up with a wrapper script (or batch file) in our current working
>>>> directory plus a bunch of class files in Mercury\classs.  With the current
>>>> install target in the compiler directory this ends up not working because only
>>>> the wrapper script ends up being copied into INSTALL_PREFIX/bin, not the class
>>>> files.  I think a better approach to handling "executables" for the java grade
>>>> would be to generate a .jar file containing all the program's class files along
>>>> with the wrapper script and have the wrapper script reference that instead of
>>>> the class files in the Mercury directory.  Any objections?
>>>>
>>>
>>> None from me.  I think this is the correct thing to do.  However, I suggest
>>> that there should be an option to disable this behaviour and allow users to
>>> package up jar files manually.
>>>  They may have other .class files to put in
>>> their jar, or they may be using Mercury in the standalone interface style.
>>
>> We should probably have an equivalent of --link-object for the Java
>> backend, e.g. something like --extra-class-file, that way users won't
>> have to package up the files themselves.
>>
>> There's no such thing as a standalone interface for the non-C backends.
>> All you need to do is export your predicates to the foreign language and
>> build as a library.
>
> Yep.  That's what I was thinking of.  That's how we use the Java backend for
> ODASE.

The only reason we have standalone interfaces is because if you are
using one of the C backends, something has to initialise the Mercury
runtime before any Mercury code is called.  For the Java and C# backends
that happens automatically.

>>> We should also check that this works correctly for buidling libraries.
>>
>> I'm not sure what you mean.
>
> I mean if you build your "foo" library as "mmc --make libfoo".  Which in C
> backends creates a libfoo.a or libfoo.so. whatever.  For java mmc --make
> (for programs) should build a Jar that can be executed with "java --jar",
> this works by putting a MainClass (sp?) attribute in the manifest of the
> .jar.

That can be done by passing an extra argument to the jar tool when we
build the archive for the executable.

>  When building libraries mmc should not check for main/2 and should
> not place the MainClass attribute in the manifest.

That already happens ;-)

Cheers,
Julien.