[m-rev.] for tryout and review: install .module_dep files to grade-specific directories

[Zoltan Somogyi]

On Sat, 31 Aug 2024 22:53:23 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > A question about the Mercury install in which this invocation of mmc
> > was looking for the Mercury standard library: was it installed with
> > compiler that had the trial diff? Because if not, then bool.module_dep
> > would not have been installed in the grade-specific install directories,
> > making this failure entirely expected.
> 
> The installation was done by doing mmake install at the top-level of
> a workspace that had the trial diff applied.  That should have used
> the correct compiler, no?

Yes, it should have.

> Looking the installation directory, there are three copies of
> bool.module_dep installed:
> 
>     ./lib/mercury/ints/java/bool.module_dep
>     ./lib/mercury/ints/csharp/bool.module_dep
>     ./lib/mercury/ints/bool.module_dep

That list is a useful cue in its own right. The last line is
for the non-grade-dependent copy for the current grade
(one issue is the question of why is this needed at all),
but the first two shows that

- .module_dep files *were* installed to grade-specific directories, but
- these seem to be the wrong directories, and
- even this was not done for all libgrades, unless the java and csharp grades
  were the *only* libgrades to install.

(The seemingly wrong directories are the same grade-specific places
where we have always put .opt files, which are grade-specific,
but it seems we search for .module_dep files differently than .opt files.
And, of course this does not seem to have been documented anywhere.)

Can you please send me (a) the output of "ls -1RF" for the install
directory, and (b) the list of libgrades?

Just as I was typing the above, I got your email. It gives me the libgrades,
but I would still like the output of ls -1RF, since it should tell me which
files are symlinks.

Thanks for your help.

> > If the install was done by a compiler with the trial diff, then I think
> > I need to enhance the debuggability of mmc --make, and we need to
> > decide what to do about six issues I posted to m-dev, before taking
> > another run at this problem.
> 
> I had a quick look at that earlier today, my only conclusion was that I need
> to take a longer look ;-)

That was my conclusion as well. I just had more time to take that longer look,
and even that resulted in as many questions as answers :-(

Zoltan