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

[Paul Bone]

On Wed, Dec 03, 2014 at 08:38:31PM +1100, Julien Fischer wrote:
> 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.

Yes, i remember now.

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

What I mean is, both of these uses of --make will need to work correctly
with the new behaviour.


-- 
Paul Bone