mkheader: Prevent 'print on closed filehandle' messages #18332
Conversation
|
This file is upstream cpan: https://metacpan.org/release/Unicode-Collate |
|
This patch will ultimately have to go upstream, as Unicode-Collate is cpan-upstream. However, it took me so long to figure out what the problem was that I would like to get confirmation of my diagnosis here. I think that the problem arose when a new version of Unicode-Collate that had At first I thought that this was a problem when a new version of ExtUtils-MakeMaker was synched into blead, so I filed https://rt.cpan.org/Ticket/Display.html?id=133762. However, I now think the problem lies entirely within Unicode-Collate. Thoughts? Thank you very much. |
|
The analysis makes sense to me. Personally I think a better change would be to modify every |
karenetheridge
added
the
cpan-dual-life
|
@jkeenan Several people think there is a better way of accomplishing this. What do you say? |
Program 'mkheader' is called from cpan/Unicode-Collate/Makefile.PL, which was recently revised to run with both strictures and warnings. Makefile.PL executes mkheader via a 'do'. This was causing the following statements to be printed during 'make' in the Perl 5 build process: printf() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1233. print() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1234. Storing the original filehandle during select(), then restoring it at the end of the loop, clears up those statements.
jkeenan
force-pushed
the
jkeenan/unicode-collate-mkheader-warnings
branch
from
5de3e0d
to
4f58a3a
Compare
|
EUMM added a workaround for the issue. This is still a bug in mkheader that should be fixed. |
Unicode-Collate ships with the Perl 5 core distribution and is invoked during Perl 5's build process. In this context, program 'mkheader' is called from cpan/Unicode-Collate/Makefile.PL, which was recently revised to run with both strictures and warnings. Makefile.PL executes mkheader via a 'do'. This was causing the following statements to be printed during 'make' in the Perl 5 build process: printf() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1233. print() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1234. Storing the original filehandle during select(), then restoring it at the end of the loop, clears up those statements. This problem was originally reported to Perl 5 in Perl/perl5#18332. Since the original report was filed, a workaround in ExtUtils::MakeMaker has silenced the statements cited above during the Perl 5 build process, but the problem in Unicode-Collate remains.
jkeenan
added
sendToCPAN
Closable?
Bug ticket opened for Unicode-Collate at https://rt.cpan.org/Ticket/Display.html?id=133952. I think this ticket itself is closable. Thank you very much. |
No one has argued that this ticket is not closable, so I'm (re-)closing it now. Thank you very much. |
jkeenan
removed
the
Closable?
Program 'mkheader' is called from cpan/Unicode-Collate/Makefile.PL,
which was recently revised to run with both strictures and warnings.
Makefile.PL executes mkheader via a 'do'. This was causing the
following statements to be printed during 'make' in the Perl
5 build process:
printf() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1233.
print() on closed filehandle $fh_h at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 1234.
Storing the original filehandle during select(), then restoring it at
the end of the loop, clears up those statements.