Closed zmughal closed 7 years ago
Hi, thanks for this. Unfotunately I don't have a Windows machine to test this on.
On face value, this would appear to be a problem with the generated makefile or Extutils::Command rather than with Term::ReadKey itself.
So, in the first instance, could you please download the distribution tarball from CPAN, unpack and run the appropriate "perl Makefile.PL" command and attach or paste here the resulting Makefile so I can compare it with that generated on platforms where I know it works fine.
Also it would be useful to know the perl version and that of ExtUtils::MakeMaker and ExtUtils::Command so I can determine whether this is a known bug in any of those.
Thanks.
Here it is: Makefile.
I didn't know GitHub supported uploading text files! I thought it only did images.
Oh, the versions of those modules:
zaki@MSI MINGW64 ~
$ pmvers ExtUtils::Command ExtUtils::MakeMaker
ExtUtils::Command: 7.12
ExtUtils::MakeMaker: 7.12
Cheers, I'll take a look in more detail tomorrow, thanks.
Doing a "test Term::ReadKey" from my Strawberry Perl Portable (PDL edition) v52211 builds and tests successfully. Maybe the problem is a conflict between the msys and mingw toolchains? I know when I set up msys previously, I had to ensure it was at the end of the PATH so the mingw would work correctly.
I'm wondering why the Makefile.PL
has this:
sub MY::realclean {
my $self = shift;
$_ = $self->MM::realclean();
s/\t/\trm -f cchars.h\n\t/;
$_;
}
instead of just this arg to WriteMakefile
:
realclean => {FILES => 'cchars.h'}
I note that @zmughal 's output said del
rather than the usual RM_F
stuff. Could you switch the build-args
thing to have NOECHO=
to make it more verbose?
It is entirely possible that the Makefile.PL has not been changed in that regard since it existed, because the history of the changes is somewhat convoluted (being partially re-created from the CPAN releases, sixteen years of my using different VCS platforms and so forth,) it is hard to know.
Not really much difference with NOECHO=" "
:
zaki@MSI MINGW64 ~
$ cpanm Term::ReadKey -f --verbose --build-args='NOECHO=" "'
[ ...snip... ]
"C:\msys64\mingw64\bin\perl.exe" -I. -IC:\msys64\mingw64\lib\perl5\core_perl genchars.pl
Writing termio/termios section of cchars.h... Done.
Checking for sgtty...
Sgtty NOT found.
Writing sgtty section of cchars.h... Done.
"C:\msys64\mingw64\bin\perl.exe" "C:\msys64\mingw64\lib\perl5\core_perl\ExtUtils\xsubpp" -noprototypes -typemap C:\msys64\mingw64\lib\perl5\core_perl\ExtUtils\typemap ReadKey.xs > ReadKey.xsc
"C:\msys64\mingw64\bin\perl.exe" -MExtUtils::Command -e mv -- ReadKey.xsc ReadKey.c
del cchars.h
gcc -c -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"2.33\" -DXS_VERSION=\"2.33\" "-IC:\msys64\mingw64\lib\perl5\core_perl\CORE" ReadKey.c
ReadKey.xs:375:20: fatal error: cchars.h: No such file or directory
compilation terminated.
dmake.exe: Error code 129, while making 'ReadKey.o'
I'm still baffled why it's doing del
!
Perhaps it might have to do with an older version of dmake
? I noticed that MSYS2 still points to the original Apache tarball.
Just a note: MSYS and MSYS2 are different systems. I have been working on a GTK-based project lately and MSYS2 is by far the easiest way to build Perl modules with GTK on Windows.
weird, I was able to get this to work by doing a manual dmake cchars.h
When installing under MSYS2/MinGW64 and using dmake, the
cchars.h
file gets deleted right before it is needed by the compilation that follows:Interim fix that prevents the deletion:
CC: @mohawk2