[m-rev.] for review: support wildcard argument expansion with MSVC

[Julien Fischer]

Hi Zoltan,

On Tue, 6 Jan 2026 at 01:59, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On Tue, 6 Jan 2026 01:04:34 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > scripts/parse_ml_options.sh-subr.in:
> > scripts/ml.in:
> >     Add a new option --use-msvc-setargv-extension, which causes the the
> >     wsetargv.obj file that enables the extension to be passed the linker.
> >     (MSVC seems rather picky about where this is positioned. A a result
> >     we do it within the ml script where we have more control over the matter.)
> >
> > compiler/Mmakefile:
>
> I am not even a novice when it comes to programming on Windows, but
> even so, I see two issues here.
>
> First, this seems to be a solution just for people working in the compiler directory.

No,  it's a solution for users of the compiler; I'm not sure how it
would help people
working in the compiler directory (who are definitely in some sort of Unix-style
shell anyway).

I added it, because the following does not currently work at the
Windows command prompt:

    mercury -f *.m

(Offhand, I can't think of anywhere else that users of mmc would need wildcard
expansion.)

> It does not help even us, Mercury developers, when working in e.g. the browser

There are no executables in the browser directory.

> or profiler directories,

It will work for the profiler, or any other executable in the Mercury system.
Which of them needs to support wildcard expansion?

> much less other Mercury users.

My immediate concern is getting the Mercury toolchain itself working.
Exposing this as a user-level feature is a different matter.

The ideal solution would be to provide wildcard expansion as part
of Mercury's standard library and then programs can selectively process
the argument vector at startup based on whether the underlying platform
does wildcard expansion or not.  This would work for all backends and
not rely on various compiler-specific runtime extensions.

Short of that, it's certainly possible to teach the compiler about all this.
(In fact, it's probably simpler than supporting it in mmake.)

> Second, it would be much better if we simply recorded the current platform
> (including in this case that MSVC was specified as the C compiler) in the ml script
> at configure time,

We record the C compiler type in the ml script at configure time.

> and let it take care of all its implications, this new one
> being just one of them.

Because that would affect any use of the ml script, not just building the
compiler.  What if a user does *not* want this runtime extension enabled
with their program?

> Is there some reason why this wouldn't work?

I think it would work, however I think you still need the ability to control
whether it is enabled or not.

> Is there some way of setting
> USING_MICROSOFT_CL_COMPILER that works in a makefile but wouldn't
> be implementable in a shell script?

Shell scripts (at least those that are generated by configure) have access
to C_COMPILER_TYPE (and FULLARCH), which will tell them what they
need to know.

...

> > +# Changes to the value of MSVC_SETARGV below, may require changes to
> > +# value of the variable main_func in ../util/mkinit.c.
> > +MSVC_SETARGV=
> > +NOLOGO_OPTS=
> >  case "${C_COMPILER_TYPE}" in
> >      msvc*)
> >          NOLOGO_OPTS="-nologo"
> > -        ;;
> > -    *)
> > -        NOLOGO_OPTS=""
> > +        case "${use_msvc_setargv_extension}" in
> > +            true) MSVC_SETARGV="wsetargv.obj" ;;
> > +        esac
> >          ;;
> >  esac
>
> Please document the meaning of this variable.

# MSVC_SETARGV is set to the name of the object file that contains the
# Microsoft C runtime extension that implements wildcard argument expansion.
# There are several versions of this object file, the one we choose below must
# match the program entry point set in value of the variable main_func in
# ../util/mkinit.c

Julien.