[m-rev.] for review: clarify how to build and install Mercury in C#/Java grades

[Zoltan Somogyi]

On Sat, 9 Aug 2025 19:38:32 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Sat, 9 Aug 2025 at 18:16, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> >
> > On Sat, 9 Aug 2025 17:03:55 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > > +The Java version of the compiler MUST be built using `mmake`'s `--use-mmc-make`
> > > +option; the build will not work otherwise. Setting the variable `GRADE` in the
> > > +invocations of `mmake` is currently required to avoid variable definition
> > > +ordering problems in `Mmake.workspace`.
> >
> > What ordering problem? A search for "order" in that file does not have
> > any relevant matches, and I couldn't find any by just reading the file.
> >
> > Are you trying to say that Mmake.workspace simply needs to know
> > the value of GRADE? In that case, is there some reason why it cannot come
> > from e.g. Mmake.params, rather than the mmake command line?
> 
> Because Mmake.common includes Mmake.workspace *before* Mmake.params.

Right, that is a problem. But it should be one that can be at least mitigated,
if not solved.

Mmake.common.in include Mmake.workspace on line 32, and Mmake.params
on line 297. Most of the stuff in between is the definitions of recursively-expanded
variables. The order in which these variables defined is immaterial, *except*
for the fact that when you have two or more definitions of the same variable,
only the last one counts. (Or maybe that should be "the last one before a given use",
but really, in a well-written makefile that should be the same thing.)

Most of the make vars that store autoconfigured values should never be set
anywhere else. I have not yet checked this assertion, but if it is true, their
definitions here can be moved before line 32.

Some other recursively-expanded definitions, such as the definition GRADE_STRING,
should also not have any other definitions, including in Mmake.params,
so can be moved anywhere, and probably *should* be moved after the inclusion
of Mmake.params, for the RHS of that definition to get any value of GRADE
from there in a more directly visible fashion.

Some other definitions yet, such as LIBRARY_INTERMODULE and LIBRARY_TRACE_MINIMUM,
should be irrelevant to Mmake.workspace, and should therefore be ok being
defined before Mmake.params (to allow override) which itself would be
before Mmake.workspace.

These should all solve part of the problem. I will try them out later, and see whether
they can solve *all* of it.

Zoltan.