[m-rev.] for review: Mercury.config*.in

[Julien Fischer]

On Tue, 24 Jun 2025 at 12:53, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Tue, 24 Jun 2025 11:55:42 +1000, Julien Fischer <jfischer at opturion.com> wrote:
>
> > > @@ -48,6 +55,35 @@ DEFAULT_MERCURY_LINKAGE=@DEFAULT_LINKAGE@
> > >
> > >  DEFAULT_GRADEFLAGS=--grade "$(MERCURY_DEFAULT_GRADE)"
> > >
> > > +# XXX zs: Why is @SHLIB_USE_INSTALL_NAME@ treated differently?
> >
> > Differently than what?
>
> Differently than all the other autoconfigured values around it. They all have
> an option name in front of them; @SHLIB_USE_INSTALL NAME@ does not.

The surrounding options are all string-valued.  SHBLIB_USE_INSTALL_NAME
is a *Boolean* option that doesn't take an argument.  As I mentioned, there are
other such Boolean options, but they are located towards the end of the list.
(That said, SHLIB_USE_INSTALL_NAME should be grouped together with the other
options that control install name settings.)

> > > +#   --cflags-for-sanitizers
> > > +#   --cflags-for-lto
> > > +#   --strip-executable-command
> > > +#   --strip-executable-shared-flags
> > > +#   --strip-executable-static-flags
> > > +#   --hwloc-libs
> > > +#   --hwloc-static-libs
> > > +#   --linker-sanitizer-flags
> >
> > I suspect Mercury.config.bootstrap was just not updated after these were added.
> > (Peter added the sanitizer stuff, so he's better placed to say for that.)
>
> The git log of these two files shows a lot of that.

It's quite easy  to forget that Mercury.config.bootstrap exists :-(

> > I don't
>
> Was something intended to follow this?

No.

> The log message of the diff that created Mercury.config.bootstrap.in, by Simon, says:
>
>     A version of Mercury.config.in that does not contain
>     any options which are not understood by the installed
>     compilers. This is used when building the stage1 compiler.
>
> If this *remains* its only purpose,

I would note that the stage 2 *_FLAGS files, e.g. library/LIB_FLAGS, contain the
line:

     --config-file ../scripts/Mercury.config.bootstrap

So, it looks as though stage 2 is also looking at it.

> then I think there is a better way to achieve it
> than the double-maintenance clusterf*ck of the current setup. I would propose that
>
> - we decide what options should be in Mercury.config, and set up Mercury.config.in
>   accordingly,
>
> - we DELETE Mercury.config.bootstrap.in, and
>
> - we add a make rule that COPIES Mercury.config to Mercury.bootstrap.config,
>   using an action such as "grep -v XYZZY < Mercury.config > Mercury.config.bootstrap",
>   with a comment that says "if you add an option to Mercury.config.in that the
>   current installed compiler does not understand, replace the XYZZY with the
>   name of that option until the installed compiler does understand it".
>
> There is a minor issue in that we don't want that grep -v to convert a line ending
> with a backslash into the last line of the file, but that is trivially solvable.
>
> Does anyone see any problems with this proposal?

I don't see any problems (other than the issue I mentioned above).

Julien.