>> perl.exe t\harness --gc-debug --running-make-test
[ ... ]
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.
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\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.
> 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.
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.
The Makefile uses backslashes because backslashes are the native path
seperator on Windows, and the command.com shell will not accept forward
slashes. My earlier patch intentionally enabled the use of backslashes
in Makefiles when compiling with MinGW, in order to get Parrot to
compile at all. Parrot now compiles, but this problem with "make test"
resulted, and I provided a workaround. 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?
> Clement Cherlin wrote:
> > ... I agree that it's a somewhat
> > ugly workaround, but it was the simplest method I could think of.
> > you suggest an alternate solution?
> TEST_FILES in makefiles/root.in has forward slashes. During creation
> the Makefile these get somewhere converted to backslashes. This
> conversion isn't needed (or wrong for MingW), if these files are part
> a perl commandline (or not at all for MingW).
> But I actually don't know, where the conversion happens, sorry.
I know where the conversion takes place, that's what my patch modifies.
The point I am trying to make is that the conversion is needed for
MinGW when using command.com, because command.com doesn't understand
forward slashes. I can't get by with forward slashes in makefiles;
Parrot will not build. Perl and the MinGW tools understand both forward
slashes and backslashes just fine. The only problem is that make treats
backslashes as an escape character when they precede an asterisk. So
the patch doubles up backslashes that precede asterisks. With this
patch, Parrot builds and make test runs.
> ... 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
this patch (#36290) works for me.
There are 2 choices :
1) revert the patch that creates the revision 8298
2) not revert and add its complement ie. #36290
But it's not possible to stay in the current position.