[m-rev.] for review: check_libgrades

[Julien Fischer]

On Sun, 21 Apr 2024, Zoltan Somogyi wrote:

> On 2024-04-21 15:13 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>> While reviewing this, I thought of the following situation.
>> Consider two programs 'a' and 'b' in the same directory, with a Mercury.options
>> file containing:
>>
>>     MCFLAGS-b = --ml not_installed
>>
>> and the invocation :
>>
>>     $ mmc --make a b
>>
>> This appears to bypass the existing libgrades check entirely :-(
>
> Do you know what code path is missing the check?

No, although I suspect we do the libgrade check *before* we have
accounted for the effects of file specific vraiables.

...

>> The rationale for all of that behaviour was that when I originally implemented
>> libgrade checks, there was no such thing as op modes and when invoking the
>> compiler to build a single file program, process_compiler_arg_build was the
>> most convenient place to do the check.
>
> In that case, I will delete that long comment as it no longer serves a purpose,
> and part of it (about no sensible Mercury.options file) is false.
> This means that there is no point in the predicate I moved it to.
>
> Would you be ok with checking libgrades in do_op_mode_args *only*
> when generating executables and libraries?

I think for users that's fine, as they are the only things they are
likely to be doing.  We don't currently do the library grade check
when building target language files (e.g. c., .java, or .cs targets)
or object files.  Since those can be dependent on installed libraries
(e.g. for interface files etc), maybe we should?

Julien.