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

[Paul Bone]

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.

>> 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.  When building libraries mmc should not check for main/2 and should
not place the MainClass attribute in the manifest.


-- 
Paul Bone