[m-rev.] for review: implement the rest of the extension changes proposal

[Zoltan Somogyi]

On 2023-08-18 15:29 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
> 
> On Fri, 18 Aug 2023, Zoltan Somogyi wrote:
> 
>> On 2023-08-18 14:04 +02:00 CEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>>> At a guess, the issue is likely that compiler/compile_target_code.m
>>> still has references to the classs directories (which are now named
>>> classes.)
>>
>> I have no idea whether that caused the bootcheck failure, but it is
>> a bug anyway. I  have committed a simple fix, and intend to fix the
>> code duplication that lead to that in the next day or two.
> 
> Thanks. I've restarted the ROTD build for today, so we'll find out if
> it works shortly.

It won't; there are few more occurrences of "classs" to be fixed.
I just pushed the diff for that.

>> Does anyone know why converting a module name with a .java or .class
>> extension generates, with --use-subdirs, a directory path that ends with
>> a directory named "jmercury", but the code referenced above in compile_target_code
>> generates the same directory path *without* the final "jmercury"?
>> What system component add that final "jmercury", and why is that done
>> separately from computing the rest of the path?
> 
> That jmercury directory is created by the Java compiler. We invoke javac
> with its -d option, which tells it the root directory in which it should
> place the generated .class files. The Java compiler will generate
> directories under that corresponding to each component of the package
> names. (The Mercury compiler only needs to create the root directory,
> i.e. the argument of the javac's -d option.)

How does the Java compiler know that the package name is "jmercury"?

Zoltan.