[m-rev.] for post-commit review: implement PROPOSED searches for .a, .init, .jar and .dll files

[Zoltan Somogyi]

On Tue, 3 Dec 2024 11:31:29 +1100, Peter Wang <novalazy at gmail.com> wrote:

> On Wed, 27 Nov 2024 20:30:41 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > This completes the initial draft of the code for
> > searches in the PROPOSED install library structure.
> > For review by anyone. I am particularly seeking feedback
> > on the updated error messages in handle_options.m.
> 
> mmc --output-libgrades produces no output after this change
> (commit 8f4aeaf02).
> 
> In detect_stdlib_grades, chosen_stdlib_dir is (still) set to `no'.

Yep, you are right, and thanks for the catch.

This bug raises an interesting issue. The comment that is now in
mercury_compile_args.m at line 109 says:

           % NOTE: The order of the flags here must be:
            %   
            %   (1) flags for detected library grades
            %   (2) flags from Mercury.config and any Mercury.options files
            %   (3) flags from environment variables
            %   (4) flags from any command line options
            %
            % The order is important, because flags given later in this list
            % can override those given earlier.

The reason why this order matters for libgrade options is that at the
moment, the libgrades accumulating string option serves two related
but nevertheless conceptually different purposes:

- it is a record of the set of grades that the mercury stdlib is
  installed in, and

- it specifies what grades a user-written library should be installed in.

They are related because the default for the latter is set by (1),
*but*, crucially, options in (2) through (4) can override this default.

This is sort-of a catch-22, because computing the set of detected library
grades *requires* looking at (2) through (4), because the name of the
location of the Mercury stdlib can be set in any of those, and of course
you need to know what directory to look in before you can search it
for installed grades. The old code before commit 8f4aeaf02 "worked"
only because it insisted on looking in the default stdlib location and (4),
not caring whether options in (2) or (3) would prove it to be the wrong place.

I think that the conceptually cleanest solution of this bug is to make
the --libgrade option serve only the second purpose, eliminating (1)
from the preference order entirely. We would compute the set of installed
stdlib grades in handle_options.m just after we compute chosen_stdlib_dir,
and record the result in a new slot in the globals structure.

We can make the set of installed stdlib grades serve as the default
for the set of grades in which to install user (i.e. non-stdlib) libraries by

- setting the initial value of libgrades not to accumulating([]), but to
  e.g. accumulating(["installed"]),

- after computing the set of installed stdlib grades, replacing any
  initial "installed" element in the value of that option with the list of
  those stdlib grades.

This allows --libgrade options to add additional grades to the stdlib ones,
while also allowing --no-libgrade to specify, as now, that we do not want
the stdlib grades.

Does anyone have a better approach for solving this problem?

Zoltan.