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

[Julien Fischer]

On Tue, 3 Dec 2024 at 18:01, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> 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.

That seems a reasonable suggestion.

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

And also allow --libgrades-{include,exclude}-component to do their thing.

Julien.