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

[Zoltan Somogyi]

On 2023-06-07 13:37 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
> I will set up some bootchecks using the infrastructure I use to test the
> releases.  (If you have specific things you want to check let me know,
> the machine I am using will be considerably quicker than the one that
> runs the nightly tests.)

Thanks for that. The things I think should be done that my laptop cannot do
in a reasonably manner, or at all, are

- bootchecks in csharp and java grades *without* -jN, so that we don't get
  effectively random failures from the compiler trying to read files that another
  compiler invocation hasn't written yet. This should allow checking whether
  this diff introduces any *new* test case failures.

  By the way, my java bootcheck finished with the expected number of failures.

- bootchecks on windows, to exercise e.g. the building of .bat files.

- likewise, bootchecks on MacOS.

- bootcheck in a .prof grade, to check the .prof extension. (The deep profiler
  is not affected by the changes in file_names.m.)

- bootchecks in setups that set the options affecting the code of file_names.m,
  the ones named in the option_extensions function in file_names.m, to any
  nondefault value. I don't have much expectation that you or anyone else in the
  Mercury group has any significant experience with these, but one can hope ...

I would be gradeful if you could do any fraction of these.

> I will also check the effects of this change on the Opturion code base.

Thanks.

>>     Add an XXX about java_object_file_extension for Julien, since he added
>>     this option (in 2001 :-().
> 
> As I did the initial work on the Java backend in 2001, that's not very
> surprising ...

The :-( was about the passage of time, as in "can you remember
what you were thinking 22 years ago?". For you, that's about half your lifetime;
for me, about a third.

>> +            % Note that the documention of --use-grade-subdirs says
>> +            % "Executables and libraries will be symlinked or copied into the
>> +            % current directory", but if this is actually done, it is done
>> +            % outside file_names.m.
> 
> Why "if this is actually done"?  Do you have some doubt as to whether it's
> being done.  (It's definitely done on my machine.)

That was not intended to express doubt; I merely wanted to point out
that this task was not done here. I have reworded the sentence.

>> +    ;       newext_int(ext_int)
>> +    ;       newext_opt(ext_opt)
>> +            % Compiler-generated interface files. and optimization files,
> 
> There's an extra full stop in there.

Fixed.

>> +            % XXX EXT JULIEN This assumes that java_object_file_extension
>> +            % has its default value, ".class".
>> +            %
>> +            % We *could* extend the ext_target_java type with a value
>> +            % that means "the value of the java_object_file_extension option",
>> +            % as we have done with e.g. ext_exec_gc. However, the original
>> +            % code of file_names.m, which had code to do the right thing
>> +            % for options such as executable_file_extension, has no such code
>> +            % for java_object_file_extension. Therefore there is no GOOD code
>> +            % to model the handling of any such new ext_target_java value on.
>> +            NewExt = newext_target_java(ext_target_java_class)
> 
> IIRC, the only reason that the --java-object-file-extension option exists is
> because we copied the corresponding C options when doing the initial setup for
> the Java backend. Since the Java compiler doesn't provide a way of letting you
> specify the output class name anyway, the existence of a Mercury compiler option
> to change it seems a bit pointless. We should delete the option.

OK, I will do so in a separate change.

> The diff is fine.

Thank you.

Zoltan.