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

[Zoltan Somogyi]

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.

> > +# XXX zs: All the differences between the values of DEFAULT_MCFLAGS
> > +# in this file and in Mercury.config.bootstrap.in should be
> > +# either documented, or erased. These differences include
> > +#
> > +#   --java-classpath (times two)
> 
> These were removed from Mercury.config in 2010, since they make the
> assumption that
> there is only one Java grade (there isn't).  They can be removed from
> Mercury.config.bootstrap as well. They cannot affect anything in stage 1
> as they are pointing to the *installation* directory and there won't be
> any .jar files installed in that while stage 1 is being built.
> 
> > +#   --grade
> 
> DEFAULT_GRADEFLAGS should work for Mercury.config.boostrap as well.
> 
> > +#   --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.

> I don't

Was something intended to follow this?

> > +#   $INSTALL_METHOD_OPT@
> 
> I suspect I simply forgot to add INSTALL_METHOD_OPT to Mercury.config.bootstrap
> after the change that added it had bootstrapped.
> 
> > +#   $LIBGRADE_OPTS@
> 
> LIBGRADE_OPTS was removed from Mercury.config so that the installed version of
> the compiler detects what library grades are installed at runtime (at least if
> you're not using mmake). This is so you can install extra library grades
> later without having to modify the Mercury.config file.  I'm not sure if
> Mercury.config.bootstrap requires it or not.

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, 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?

Zoltan.