[m-rev.] diff: workaround a problem with 'mmc --make in the Java grade

[Julien Fischer]

On Thu, 3 Sep 2015, Peter Wang wrote:

> On Thu, 3 Sep 2015 20:01:08 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> A couple of things:
>>
>> 1. I think it would be useful if the predicate target_is_java (along with
>> target_is_c, target_is_csharp etc) were added to the builtin module.  Any
>> objections?
>
> I don't think there is much to gain from them.  If you are doing
> target-specific things you will usually need to write other foreign code
> anyway.

Of course, but that doesn't mean I should have to keep writing the same
piece of foreign code over and over again.

> Otherwise, not in builtin, please.  Hardly anyone will call them.

Ok, it was just a thought.

...

>> Workaround a problem with 'mmc --make' when the Mercury compiler is built in
>> the Java grade.  In that grade io.progname will return the program name as
>> 'top_level' because that is what the name of the top-level compiler module is
>> (in the Java grade the program name is set in the top-level module).  This
>> means that when '--make' attempts to invoke the compiler that it tries to
>> invoke the executable 'top_level', which won't exist because we rename it to
>> 'mercury_compile'.
>>
>> compiler/make.module_target.m:
>>      If the compiler is built in the Java grade then don't attempt to invoke
>>      it using the name returned by io.progname, instead just use the value
>>      of the environment variable MERCURY_COMPILER or, if that is not set, just
>>      'mmc'.
>>
>>      Simplify how we generate an error message.
>
> How about we rename mercury_compile.m (say, to mercury_compile_main.m)
> and let mercury_compile.m be the file that contains main/2?

That is, replacing top_level.m with mercury_compile.m, that's fine by
me.

Julien.