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

[Peter Wang]

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.

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

> 
> 2. In conjunction with the change to build Java executables as Java 
> archives, it's now fairly straightforward to get a working Mercury
> compiler compiled in Java.  (For "working" read "can compile the sample
> programs in the Java grade".)
> 
> -------------------
> 
> Workaround a problem with 'mmc --make' in the Java grade.
> 
> 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?

Peter