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

[Julien Fischer]

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.

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

Julien.