>>        perl.exe t\harness --gc-debug --running-make-test

> t\library\*.t

> Clement Cherlin (via RT) wrote:

> >>        perl.exe t\harness --gc-debug --running-make-test

> > t\library\*.t

> [ ... ]

> Doesn't a) perl take forward slashes too and b) harness do the glob
> anyway? If the shell globs the test args, we'll run into commandline
> length issues sooner or later.

> leo

Clement Cherlin wrote:
> --- Leopold Toetsch via RT <parrotbug-follo...@parrotcode.org> wrote:
>>Doesn't a) perl take forward slashes too and b) harness do the glob
>>anyway? If the shell globs the test args, we'll run into commandline
>>length issues sooner or later.

>>leo

> Perl will accept both forward and backward slashes on Win32, and the
> harness does do the globbing. My patch only deals with the fact that
> make is treating "\*" as an escaped asterisk, and unescaping it to just
> "*". I add an additional backslash, thus escaping the backslash instead
> of the asterisk. Make translates "\\*" to "\*" and all is well.

> Clement Cherlin wrote:
> > --- Leopold Toetsch via RT <parrotbug-follo...@parrotcode.org>
> wrote:

> >>Doesn't a) perl take forward slashes too and b) harness do the glob

> >>anyway? If the shell globs the test args, we'll run into
> commandline
> >>length issues sooner or later.

> >>leo

> > Perl will accept both forward and backward slashes on Win32, and
> the
> > harness does do the globbing. My patch only deals with the fact
> that
> > make is treating "\*" as an escaped asterisk, and unescaping it to
> just
> > "*". I add an additional backslash, thus escaping the backslash
> instead
> > of the asterisk. Make translates "\\*" to "\*" and all is well.

> Yes. But shouldn't in that case the patch convert the backslashes to
> just forward slahes - or much better not backslash it in the first
> place
> (and possibly quote the *.t args)?

> The patch reverses a wrong action (backslashing) that happens earlier

> somewhere in config.

> leo

> Clement Cherlin wrote:

> > ... I agree that it's a somewhat
> > ugly workaround, but it was the simplest method I could think of.
> Can
> > you suggest an alternate solution?

> TEST_FILES in makefiles/root.in has forward slashes. During creation
> of
> the Makefile these get somewhere converted to backslashes. This
> conversion isn't needed (or wrong for MingW), if these files are part
> of
> a perl commandline (or not at all for MingW).

> But I actually don't know, where the conversion happens, sorry.

> leo

Clement Cherlin wrote:
> ... I agree that it's a somewhat
> ugly workaround, but it was the simplest method I could think of. Can
> you suggest an alternate solution?

># New Ticket Created by  Clement Cherlin
># Please include the string:  [perl #36290]
># in the subject line of all future correspondence about this issue.
># <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36290 >

>François PERRAD wrote:

> > Please, revert this patch (r8298)
> > With MinGW & cmd.exe :
> >         $ make test
> >         perl.exe t\harness --gc-debug --running-make-test
>t\library\*.t
> > t\op\*.t t\pmc\*.t t\native_pbc\*.t imcc\t\*\*.t t\dynclass\*.t
> > t\src\*.t t\perl\*.t
> >         FAILED--no tests were run for some reason.

> > In its initial mail, Clement Cherlin wrote : "I still haven't gotten
> > compilation to finish ..."

> > Francois Perrad.

>Not to worry, I have a one-line fix for that problem. Mingw32-make
>treats '\*' as a backslash escaping an asterisk, so it turns that into
>just '*'. I changed lib/Parrot/Configure/Step.pm to substitute '\\*'
>for '\*'. I can now run 'make test'.

>I have only tested this patch with mingw32-make, so I would appreciate
>it if others could test it with nmake / dmake to make sure they don't
>choke on the extra backslashes.