[m-rev.] systematic problem with tests/valid* for C#

[Zoltan Somogyi]

On 2023-10-04 15:50 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote
> We also don't support mmake with Java. The issue here is that
> 
> 1. Some mmake support for Java dates back to the original addition of the
>    Java backend, when mmc --make wasn't really a thing.
> 2. Some mmake support for C# is (probably) left over from the old .NET
>    backend.
> 3. Some mmake support for C# is (probably) just the result of
>    copy-and-pasting when the present C# backend was added.
> 4. Some mmake support for both languages may be necessary for mmake's
>    --use-mmc-make option to work.
> 
> We need to maintain support for (4), but everything else could go.
> Unfortunately, that would mean working out which of the categories
> each piece of C# or Java support in mmake falls into.

In a separate diff, I will add the above to write_deps_file.m as a comment.

>> scripts/Mmake.rules:
>> scripts/Mmake.vars.in:
> 
> What's the change here?

It seems I posted for review a version of the log file before I finished it.
To answer your question, and Peter's in the same vein from the next email
in this thread, here is the end of the completed log file:

scripts/Mmake.vars.in:
    Specify the names of mmake variables holding the names of sets of files
    with a given extension directly, since for some of them, adding an "s"
    at the end of the name of the extension does not generate the name
    of the corresponding mmake variable anymore.

scripts/Mmake.rules:
    Use the directly specified mmake variable names from Mmake.vars.in
    in the rule for installing lbraries. Temporarily add some debugging
    output to make suree that the updated nested mmake variable references
    work as intended.

tools/bootcheck:
    Specify the names of mmake targets for making all the files in a program
    with a given extension directly, since adding an "s" at the end of the
    name of the extension does not generate the name of the corresponding
    mmake target anymore.

    Print timestamps around the action of checking namespace cleanliness,
    to allow the time taken by that action to be measured. (I kept track
    of bootchecks as they happened while working on this diff, and found
    this time to be nontrivial.)

>> --- a/NEWS.md
>> +++ b/NEWS.md
>> @@ -58,6 +58,79 @@ Changes that may break compatibility
>>
>>  * We have dropped support for the x86 (32-bit) version of Cygwin.
>> > +* We have changed the meaning of `mmc --make name.cs`.
>> +
>> +  We have long had two conventions for the names of mmc --make targets
>> +  for building all the files of a particular kind needed by a program.
>> +  The original convention was
>> +
>> +  - target `program.cs` builds the .c files of all the modules of `program`
>> +  - target `program.os` builds the .o files of all the modules of `program`
> 
> The only one of the 's' targets that is publicly documented is .all_ints, which
> raises the question of whether we need to announce these changes at all?

Addressed in the reply to Peter's email.

> The diff looks fine otherwise.

Thank you. I followed your other suggestions.

Zoltan.