[m-rev.] diff: workaround a problem with 'mmc --make in the Java grade
jfischer at opturion.com
Thu Sep 3 21:01:57 AEST 2015
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
> 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
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
>> 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
>> 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
More information about the reviews