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

Julien Fischer jfischer at opturion.com
Mon Jun 19 11:13:23 AEST 2023


On Mon, 19 Jun 2023, Zoltan Somogyi wrote:

>
> On 2023-06-18 14:20 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>>> I would therefore propose that we put all object files into a subdir
>>> named "os", as the new filename translation algorithm already does.
>>
>> I don't have any particular objection to that, although I would note
>> that it breaks the pattern we currently have for the Mercury
>> subdirectory that files with extension .foo go in the directory foos.
>
> Files with extension ".pic_o" already go in "os", and files with extension
> ".dv" already go in "deps".
>
>>> 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.
>>
>> The use of MSVC with Mercury is such a niche use-case, that I can't
>> imagine backwards compatibility being an issue.
>
> The attached diff implements this proposal. For you to try out, including
> with MSVC.

That gets us further (i.e. when compiling hello world, hello.obj is now
successfully created).  The next mismatch is:

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("_init.obj"))/newext_target_init_obj(ext_init_obj_obj_opt):
Mercury\objs\hel
lo_init.obj vs Mercury\os\hello_init.obj

Julien.


More information about the reviews mailing list