[m-rev.] for review: fix a heisenbug in grade_lib

[Julien Fischer]

On Sun, 21 Apr 2024, Zoltan Somogyi wrote:

> Fix a problem with grade_lib/Mmakefile ...
> 
> ... and warn about any similar problems in the future.
> 
> grade_lib/Mmakefile:
>     The grade_lib directory had a strange Heisenbug that could occur
>     when one did this simple command sequence in an initially clean workspace:
>
>     - run prepare.sh and configure
>     - execute mmake -jN
>
>     The mmake would often fail, with the symptom being a failure to find
>     the definitions of several symbols when linking the executables of
>     one or more of the three programs in the grade_lib directory.
>
>     The immediate cause of the bug is the -jN option to mmake.
>     Mercury.modules is listed as the first item in $(DEPENDS),
>     so without -jN, it would be built first. With -jN, however, mmake can,
>     and often will, start building the choose_grade.depend, test_grades.depend,
>     and try_all_grade_structs.depend targets *before* Mercury.modules
>     has been created. If that happens, then the mmc invocation for
>     e.g. the choose_grade.depend target will OMIT the modules of the
>     grade_lib package from the list of current-directory modules
>     that should be linked into the choose_grade executable (which is
>     visible as the .mods entry in e.g. choose_grade.dv) because
>
>     - the names of the filed containing these modules, grade_solver.m,

s/filed/files/

>       do NOT correspond to the FULLY QUALIFIED names of those modules,
>       in this case grade_lib.grade_solver, and
>
>     - in the absence of the Mercury.modules file, the mmc
>       --generate-dependencies invocation will therefore consider these
>       modules to NOT be local modules that need to be linked into the
>       executable.
>
>     Making Mercury.options a prerequisite for the depend targets
>     of the executables in this module fixes the bug.

...

That looks fine otherwise.

Julien.