[m-rev.] for post-commit review: propose a new structure for options.m

[Julien Fischer]

On Thu, 12 Jun 2025 at 23:23, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> On Mon, 9 Jun 2025 14:26:08 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > I realise it's rather late in the day for a review of this.
>
> But still welcome. My reply is also late ...
>
> > On Wed, 4 Jun 2025 at 12:38, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> > >      ;       oc_link
> > > +            % Options that control how executables, or their equivalents
> > > +            % for some target languages, are generated.
> > > +            % XXX Subdivide into oc_link_c/oc_link_java/oc_link_csharp.
> > > +            % XXX Are the oc_link options that apply to more than one target?
> >
> > At the moment, I don't think so.
>
> The options that specify the location of the installed Mercury system are needed
> to find the set of installed grades, and in that sense are needed regardless of the
> target language. And there are some options that look like they were intended to be
> options for C, but which are used for C# as well.
>
> > (A subset of the C runtime flags are supported
> > the Java backend.)
>
> I saw no sign of that while working on this diff.

Unless your work involved the file java/runtime/MercuryOptions.java
you wouldn't have.
Options to the Mercury runtime are specified via the MERCURY_OPTIONS environment
variable.  Both the C and Java runtimes support this (the latter for
just a single option ...)

The --runtime-flags option causes the compiler to inject runtime flags
directly into
the generated code (in the _init.c file in C grades).  It is not
currently supported by the
Java backend, but potentially could be.  That's what I meant by the above.

...

> > > +optdef(oc_config,   max_jump_table_size,                 int(0)).
> > > +    % 0 indicates jump tables can be any size.
> > > +    % XXX This option works around limitations in 1998 C compilers.
> > > +    % Its value should be set automatically by handle_options.m
> > > +    % based on the value of the c_compiler_type option.
> >
> > As I am sure you are aware, this option predates the addition of
> > c_compiler_type. There are two C compilers that require this:
> >
> > 1. lcc -- this no longer an issue as Mercury can no longer be
> >    built with lcc.
> >
> > 2. MSVC -- the configure sets the maximum jump table size to 512
> >    "to avoid a fixed limit in the compiler".
>
> At the moment, handle_options.m does not set, or even mention,
> this option.
>
> I presume that the reason for handling these implications in configure.ac
> is that we need the results in sh scripts, as well as in the compiler.

In this case I don't think so. --max-jump-table-size is a Mercury compiler
option that affects the C code we generate. The mgnuc script which (sometimes)
handles that C code doesn't need to know anything about it.

That workaround almost certainly predates my addition of the c_compiler_type
mechanism. Instead of getting of configure to look at it, we should just get
handle_options.m to set it based on the value of c_compiler_type option.
(The same arguably goes for a number of other workarounds -- where
they can be built into the compiler, they should be.)

Julien.