[m-rev.] for review: check_libgrades

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun Apr 21 15:26:26 AEST 2024


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?

> Whether the libgrade check should cache stuff, depends on what the expected
> behaviour for the above is.  Is the granularity of the check a superset of
> all libraries used by all targets built in an invocation, or is it more specific
> that that?

I thought the values of both the mercury_library option and the grade should be
constants throughout a compiler execution, but with mmc --make *and* target-specific
mmake variables such as MCFLAGS-b, neither is true. I will back out the change to
check_libgrades.m. I *could* make the cache operate only if the values of those two things
are the same at the time of the check as at the time when the caches was filled, but
that is probably not worthwhile.

>> @@ -920,6 +885,10 @@ do_op_mode_args(ProgressStream, ErrorStream, Globals,
>>          ExtraObjFiles = []
>>      ),
>> > +    % XXX NEW If LibgadeCheckSpecs is nonempty, we know that the linking step
>> +    % will fail.
>> +    % I (zs) don't think we should execute the following linking code
>> +    % in that case, though I could be persuaded otherwise.
> 
> At a guess, this behaviour has been introduced by the one of the many
> refactorings of op modes and / or handling or error messages.  There is
> certainly no point in progressing to the link step if the library grade
> check has failed.

Ok, I will make that change.

> 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?

Zoltan.


More information about the reviews mailing list