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

[Julien Fischer]

On Mon, 19 Jun 2023, Zoltan Somogyi wrote:

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

".exe"

(This case, incidentally, is MSVC -- I'm using MSYS2 as the build
environment which is why there are references to "x86_64-w64-mingw32"
above.)

> And just to jump ahead, what are the values of the other options
> listed in the option_extensions function in file_names.m?

     --executable-file-extension ".exe"
     --library-extension ".lib"
     --object-file-extension ".obj"
     --pic-object-file-extension ".o"
     --shared-library-extesnion ".lib"

--pic-object-file-extension is not applicable on Windows;
--shared-library-extension should be ".dll", but we do not
currently support shared libraries on Windows.

> And which subdir name, if any, do you prefer?

I would put them in bin.

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

Clearly ;-)  I have no objection to disabling the sanity checks in
the specific case above.

Julien.