[m-rev.] for review: start using the new code in file_names.m

[Zoltan Somogyi]

On 2023-06-19 13:14 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
> $ mmc --use-grade-subdirs --make hello
> Making Mercury\int3s\hello.int3
> Making Mercury\ints\hello.int
> Making Mercury\hlc.gc\x86_64-w64-mingw32\Mercury\cs\hello.c
> Making Mercury\hlc.gc\x86_64-w64-mingw32\Mercury\os\hello.obj
> hello.c
> Uncaught Mercury exception:
> Software Error: predicate
> `parse_tree.file_names.module_name_to_file_name'/9: Unexpected: FILENAME
> MISMATCH 1 for
> ext_other(other_ext(".exe"))/newext_exec_gs(ext_exec_exec_opt):
> Mercury\hlc.gc\x86_64-w64-mingw32\Mercury\exes\hello.exe vs
> Mercury\hlc.gc\x86_64-w64-mingw32\Mercury\bin\hello.exe

What is the value of executable_file_extension option
in that case? And just to jump ahead, what are the values
of the other options listed in the option_extensions function
in file_names.m?

And which subdir name, if any, do you prefer? I never understood
why the old algorithm had code to put files with .exe extensions
into the *current* directory, but then let that code be overridden
by the value of executable_file_option *also* being set to .exe,
nor did I understand why there were different rules for executables
with different extensions at all. (And the same for libraries.)

At this point, I would propose that we disable sanity checks in the
specific case where the newext asks for the lookup of the value
of an option. For those, what should matter is whether all parts of the
system agree on the directory where to put the file, not whether this
agrees with the old system, because I think the old system needs
some rationalization anyway.

Zoltan.