[m-rev.] for review: filename extensions

[Zoltan Somogyi]

2020-08-14 17:51 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>
> On Thu, 13 Aug 2020, Zoltan Somogyi wrote:
> 
>> For review by anyone. I have bootchecked this in C# and Java grades
>> as well as C grades.
> 
> For future changes building on this, I suspect where we may see any
> breakage is in Windows vs. non-Windows systems.

Yes; I don't intend to commit any changes that affect Windows-specific
extensions without asking someone who uses Windows to try it out first.

Actually, I also did two bootchecks with hlc.gc with Mmake.stage.params
containing --use-subdirs and --use-grade-subdirs respectively.
Both failed immediately after making stage 2 dependencies,
complaining about undefined mmake variables such as mer_std.mhs.
However, this was not due to this diff; a workspace without this diff
generated the same error under the same conditions. I am guessing,
since I haven't looked into this yet, that the compiler is generating
a definition not for e.g. mer_std.mhs, but for Mercury/mhs/mer_std.mhs,
because it is treating the mmake target name as if it were a file name,
which is exactly the kind of problem that this diff documents, and
whose future fix it is trying to prepare for.

The failures were news to me, since I never use subdirs of either flavor
with C grades. Does anyone? Is it even supposed to work?

>> scripts/c2init.in:
>> scripts/canonical_grade.in:
>> scripts/mdprof.in:
>> scripts/mercury.in:
>> scripts/mercury_update_interface.in:
>> scripts/mgnuc.in:
>> scripts/mkfifo_using_mknod.in:
>> scripts/ml.in:
>> scripts/mmake.in:
>> scripts/mmc.in:
>> scripts/mprof.in:
>> scripts/prepare_install_dir.in:
> 
> I don't think this list of files should be here; the diff doesn't contain any
> changes for these files.

I committed those changes separately, but forgot to remove that block.
Thanks for catching it.

> The diff looks fine otherwise.

Thank you.

Zoltan.