[m-rev.] for review: Defer SHARED_LIBS assignment in ml script.

[Peter Wang]

On Thu, 14 Dec 2023 15:31:20 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2023-12-14 15:27 +11:00 AEDT, "Peter Wang" <novalazy at gmail.com> wrote:
> > On Thu, 14 Dec 2023 15:12:31 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> >> 
> >> On Thu, 14 Dec 2023, Peter Wang wrote:
> >> 
> >> > scripts/ml.in:
> >> >    Assign SHARED_LIBS only when it will actually be used,
> >> >    as the default value of SHARED_LIBS set by configure
> >> >    may invoke "gcc -print-libgcc-file-name" in a command substitution.
> >> 
> >> That's fine. Presuambly, this is just for performance reasons?
> > 
> > Yes, though I haven't tried to measure the difference.
> > 
> > I noticed it because nearly 80% the calls to ccache on my system were
> > "Uncacheable" and, of those, 94% were due to "No input file" --
> > likely most of those due to ml running "gcc -print-libgcc-file-name".
> 
> What do we gain by executing gcc --print-libgcc-file-name in the ml script at all?
> Under what circumstances is its output going to change? Why can't we execute
> that command in the configure script itself, and bake not the command, but
> its *output* into the ml script?

The output is dependent on gcc version,
e.g. /usr/lib64/gcc/x86_64-unknown-linux-gnu/12.2.0/libgcc.a

The current setup allows you change gcc version without necessarily
rebuilding the Mercury system (or reconfiguring, at least).

Peter