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

[Zoltan Somogyi]

On 2023-06-18 13:48 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
> 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(".obj"))/newext_target_obj(ext_obj_obj_opt):
> Mercury\hlc.gc\x86_64-w64-mingw
> 32\Mercury\objs\hello.obj vs
> Mercury\hlc.gc\x86_64-w64-mingw32\Mercury\os\hello.obj

May I presume that the directory name mismatch, objs vs os,
is the only REAL mismatch? I don't think anything in my diff could be
responsible for a newline char being inserted after "mingw".

Another question: is there some point in storing object files
in subdirectories named "objs" when their suffix is ".obj"
but storing them in subdirectories named "os" when their
suffix is ".o"? Given that the string "objs" does not appear
in filenames.m, the subdir name "objs" was obviously constructed
by filenames.m from the extension ".obj", which the ext_obj_obj_opt
says was taken from value of the object_file_extension option.
It therefore seems to be that putting such files in a subdir named
"objs" was never a CONSIDERED choice. I would therefore propose
that we put all object files into a subdir named "os", as the new
filename translation algorithm already does.

I could add some code to the OLD filename translation
algorithm to put all files whose suffix matches the object_file_extension
option, or its pic variant, into a directory named "os".
That would fix this abort, though not in a backward-compatible way,
and would allow the search for other mismatches to continue.

Would that work for you, and for everyone else?

Zoltan.