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

[Zoltan Somogyi]

On Tue, 6 Jan 2026 14:38:17 +1100, Julien Fischer <jfischer at opturion.com> wrote:

> Hi Zoltan,
> 
> On Tue, 6 Jan 2026 at 03:33, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> > On Tue, 6 Jan 2026 03:03:19 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > > 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.)
> >
> > mmc --make-int *.m? No, this does not invoke ml, but then, I don't think
> > mercury -f *.m does either.
> 
> Neither of those things invokes ml.

As I said.

> I'm not sure what that has to do
> with whether
> the mercury_compile executable expands wildcard arguments or not.

Both invoke mmc, and it makes sense for both to be given an argument list
that contains wildcards. As this entry ....

> The installed executables in the Mercury system are listed below.
> I've marked the ones where supporting wildcard expansion would likely
> be useful with **.
> 
> ./compiler/mercury_compile.exe **

... acknowledges.

> mercury -f *.m specifically is completely useless to a Mercury
> developer working in the
> browser directory because that means they are trying to work on
> Mercury itself at
> the Windows command prompt (i.e. cmd.exe).  Our build system doesn't
> support that.
> 
> That mmc -f *.m could be useful in the browse directory is beyond dispute.
> However, if you are working in the browser directory, then you are also using
> a shell that supports wildcard expansion.

I will take your word for that, since I have no applicable experience.

> > We could
> >
> > - extend the configure script with a flag that sets the default for this to
> > either on or off.
> >
> > - embed this default in ml at configure time, and
> >
> > - let an environment variable override the default.
> >
> > > > 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.
> >
> > The above would do that. It would do that for *all* uses of ml, not
> > just when ml is invoked by mmc.
> 
> That seems more complicated. Adding an extra configure flag that
> controls this just provides scope for users to turn it off and then wonder
> why mercury -f *.m doesn't work when they use MSVC.

I only added that part because you talked about the importance of
letting users choose what they want.
 
> The version I have in this diff works for all uses of ml

That's my point: it works for ml, but not for mmc.

> provided you
> set the --use-msvc-setargv-extension flag to the ml script via the
> MLFLAGS or EXTRA_MLFLAGS variables.  (It obviously does not work
> for the compiler in general, because mmc --make does not use the ml
> script.)

Here is one scenario in which it would useful for it to work for mmc.

> This diff is not intended as a general solution for Mercury users to
> add wildcard
> expansion to their own programs.

I understand that. My question is: wouldn't a general solution be more useful?
Yes, I know it would be harder, and I am NOT asking it for it to be in this change.
However, it would be nice to know whether this part-solution fits into an eventual
solution for all of mmc, or even for all Mercury programs. We could do it by adding
a flag to the getopt.m predicate that expands @file arguments, a flag that asks it to
also expand all glob patterns. I am sure a web search will find existing code for
glob expansion; we just need to translate it to Mercury.
 
> I suggest we get Mercury itself working and then worry about if / how we
> make this available to users.

Agreed. I have no objection to you committing this diff with the updated
documentation of MSVC_SETARGV.

Zoltan.