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

Julien Fischer jfischer at opturion.com
Tue Jan 6 14:38:17 AEDT 2026


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. I'm not sure what that has to do
with whether
the mercury_compile executable expands wildcard arguments or not.

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 **
./deep_profiler/mdprof_cgi.exe
./deep_profiler/mdprof_create_feedback.exe
./deep_profiler/mdprof_dump.exe
./deep_profiler/mdprof_procrep.exe
./deep_profiler/mdprof_report_feedback.exe
./deep_profiler/mdprof_test.exe
./mfilterjavac/mfilterjavac.exe
./profiler/mercury_profile.exe (**)
./slice/mcov.exe (**)
./slice/mdice.exe
./slice/mslice.exe
./slice/mtc_diff.exe
./slice/mtc_union.exe (**)
./util/info_to_mdb.exe
./util/mdemangle.exe
./util/mfiltercc.exe
./util/mkinit.exe

mkinit could also be on that list, but we currently don't use it in a
way that requires
wildcard expansion to work.

> > > It does not help even us, Mercury developers, when working in e.g. the browser
> >
> > There are no executables in the browser directory.
>
> But e.g. mercury -f *.m is useful even in that case.

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.

...

> 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.

The version I have in this diff works for all uses of ml 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.)

This diff is not intended as a general solution for Mercury users to
add wildcard
expansion to their own programs. Its intended purpose is to add
wildcard expansion
to select executables in the Mercury when Mercury is installed in the usual
way (i.e. using mmake).

I suggest we get Mercury itself working and then worry about if / how we
make this available to users.

> > > 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
>
> That's fine, but I would explicitly specify that "" means the absence of such
> an object file.

I've modified it to say that it is set to the name of the object file when we
want to use the runtime extension and empty otherwise.

Julien.


More information about the reviews mailing list