Skip Menu |

This queue is for tickets about the ExtUtils-Helpers CPAN distribution.

Report information
The Basics
Id: 123217
Status: rejected
Priority: 0/
Queue: ExtUtils-Helpers

People
Owner: Nobody in particular
Requestors: cpan [...] tlinx.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.026
Fixed in: (no value)



Subject: test failure
Test with "-w" switch in make_executable fails because of -w sswitch: Show quoted text
> make test
PERL_DL_NONLAZY=1 "/home/perl/perl-5.26.0/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/make_executable.t ... /usr/bin/env: ‘perl -w’: No such file or directory t/make_executable.t ... 1/7 # Failed test 'test_exec 42 return value ok' # at t/make_executable.t line 25. # got: '127' # expected: '42' /usr/bin/env: ‘perl -w’: No such file or directory # Failed test 'test_exec 51 return value ok' # at t/make_executable.t line 25. # got: '127' # expected: '51' /usr/bin/env: ‘perl -w’: No such file or directory # Failed test 'test_exec 0 return value ok' # at t/make_executable.t line 25. # got: '127' # expected: '0' # Looks like you failed 3 tests of 7. t/make_executable.t ... Dubious, test returned 3 (wstat 768, 0x300) Failed 3/7 subtests (less 1 skipped subtest: 3 okay) t/man_pagename.t ...... ok t/split_like_shell.t .. ok t/tilde.t ............. ok Test Summary Report ------------------- t/make_executable.t (Wstat: 768 Tests: 7 Failed: 3) Failed tests: 2, 4, 6 Non-zero exit status: 3 Files=4, Tests=30, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.31 cusr 0.03 csys = 0.38 CPU) Result: FAIL Failed 1/4 test programs. 3/30 subtests failed. Makefile:882: recipe for target 'test_dynamic' failed ---removing -w from inside test, get: Show quoted text
> gvim t/make_executable.t
Ishtar:../ExtUtils-Helpers-0.026-6> make test PERL_DL_NONLAZY=1 "/home/perl/perl-5.26.0/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/make_executable.t ... ok t/man_pagename.t ...... ok t/split_like_shell.t .. ok t/tilde.t ............. ok All tests successful. Files=4, Tests=30, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.31 cusr 0.04 csys = 0.39 CPU) Result: PASS
Subject: Re: [rt.cpan.org #123217] test failure
Date: Mon, 9 Oct 2017 09:31:25 +0200
To: bug-ExtUtils-Helpers [...] rt.cpan.org
From: Leon Timmermans <fawaka [...] gmail.com>
On Sun, Oct 8, 2017 at 6:52 AM, Linda Walsh via RT < bug-ExtUtils-Helpers@rt.cpan.org> wrote: Show quoted text
> Sun Oct 08 00:52:56 2017: Request 123217 was acted upon. > Transaction: Ticket created by cpan@tlinx.org > Queue: ExtUtils-Helpers > Subject: test failure > Broken in: 0.026 > Severity: Critical > Owner: Nobody > Requestors: cpan@tlinx.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=123217 > > > > Test with "-w" switch in make_executable fails because of -w sswitch:
> > make test
> PERL_DL_NONLAZY=1 "/home/perl/perl-5.26.0/usr/bin/perl" > "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef > *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/make_executable.t ... /usr/bin/env: ‘perl -w’: No such file or directory > t/make_executable.t ... 1/7 > # Failed test 'test_exec 42 return value ok' > # at t/make_executable.t line 25. > # got: '127' > # expected: '42' > /usr/bin/env: ‘perl -w’: No such file or directory > > # Failed test 'test_exec 51 return value ok' > # at t/make_executable.t line 25. > # got: '127' > # expected: '51' > /usr/bin/env: ‘perl -w’: No such file or directory > > # Failed test 'test_exec 0 return value ok' > # at t/make_executable.t line 25. > # got: '127' > # expected: '0' > # Looks like you failed 3 tests of 7. > t/make_executable.t ... Dubious, test returned 3 (wstat 768, 0x300) > Failed 3/7 subtests > (less 1 skipped subtest: 3 okay) > t/man_pagename.t ...... ok > t/split_like_shell.t .. ok > t/tilde.t ............. ok > > Test Summary Report > ------------------- > t/make_executable.t (Wstat: 768 Tests: 7 Failed: 3) > Failed tests: 2, 4, 6 > Non-zero exit status: 3 > Files=4, Tests=30, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.31 cusr > 0.03 csys = 0.38 CPU) > Result: FAIL > Failed 1/4 test programs. 3/30 subtests failed. > Makefile:882: recipe for target 'test_dynamic' failed > > ---removing -w from inside test, get: > >
> > gvim t/make_executable.t
> Ishtar:../ExtUtils-Helpers-0.026-6> make test > PERL_DL_NONLAZY=1 "/home/perl/perl-5.26.0/usr/bin/perl" > "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef > *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/make_executable.t ... ok > t/man_pagename.t ...... ok > t/split_like_shell.t .. ok > t/tilde.t ............. ok > All tests successful. > Files=4, Tests=30, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.31 cusr > 0.04 csys = 0.39 CPU) > Result: PASS >
What value does «perl -V:startperl» give you? Did you customize that when configuring perl? Leon
From: perl-diddler [...] tlinx.org
I set it to the recommended value: Show quoted text
> perl -V:startperl
startperl='#!/usr/bin/env perl'; Also, BTW, I've been told (in critique of my own code), that I shouldn't use "perl -w" but should "use warnings" instead. I often have to fix that in some of my older programs.
Subject: Re: [rt.cpan.org #123217] test failure
Date: Mon, 9 Oct 2017 17:55:56 +0200
To: bug-ExtUtils-Helpers [...] rt.cpan.org
From: Leon Timmermans <leont [...] cpan.org>
On Mon, Oct 9, 2017 at 1:16 PM, perl-diddler@tlinx.org via RT < bug-ExtUtils-Helpers@rt.cpan.org> wrote: Show quoted text
> Queue: ExtUtils-Helpers > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=123217 > > > I set it to the recommended value: >
> > perl -V:startperl
> startperl='#!/usr/bin/env perl'; >
Who recommended that? This will break both Module::Build and Module::Build::Tiny/ExtUtils::Helpers. It only doesn't break ExtUtils::MakeMaker because it rejects your value entirely (and uses perlpath instead). Show quoted text
> Also, BTW, I've been told (in critique of my own code), that I shouldn't > use "perl -w" but should > "use warnings" instead. I often have to fix that in some of my older > programs. >
Wise or not, people use it, and hence ExtUtils::Helpers has to support it. Leon
From: perl-diddler [...] tlinx.org
If you google on /usr/bin/env, you'll find some places, including, https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my https://www.cyberciti.biz/tips/finding-bash-perl-python-portably-using-env.html Maybe from perlmonks as well. Also, have had problems switching between different versions of perls -- some scripts have different locations for perl embedded in their headers. What I wanted was for it to use the perl in my PATH, as I'd adjust my PATH to use different perls for testing. As for "use warnings" -- even the current manpage says "use warnings" is preferred over "-w" (from https://perldoc.perl.org/warnings.html): What's wrong with -w and $^W Although very useful, the big problem with using -w on the command line to enable warnings is that it is all or nothing. Take the typical scenario when you are writing a Perl program. Parts of the code you will write yourself, but it's very likely that you will make use of pre-written Perl modules. If you use the -w flag in this case, you end up enabling warnings in pieces of code that you haven't written. Having a module that supports or allows itself to be run with "-w", is different than enforcing it for perl. While users may use "-w" for simplicity, a module released on CPAN shouldn't use it because it either 1) will turn on warnings where modules don't expect them to be on, or 2) won't turn on warnings for the module using "-w", as "use warnings" should have been used to turn on warnings for that module. I'm not sure that Build is the right place to enforce allowing "-w" on the perl invocation line for the rest of the perl ecosystem.
On Mon Oct 09 12:50:42 2017, perl-diddler@tlinx.org wrote: Show quoted text
> If you google on /usr/bin/env, you'll find some places, including, > > https://unix.stackexchange.com/questions/29608/why-is-it-better-to- > use-usr-bin-env-name-instead-of-path-to-name-as-my > > https://www.cyberciti.biz/tips/finding-bash-perl-python-portably- > using-env.html > > Maybe from perlmonks as well.
None of those recommend modifying the value for startperl. None. Show quoted text
> Also, have had problems switching between different versions of perls > -- some scripts have different locations for perl embedded in their > headers. > > What I wanted was for it to use the perl in my PATH, as I'd adjust my > PATH to use different perls for testing.
Installed perl scripts come with their dependencies. They shouldn't be using "any perl" as another perl may lack those dependencies, hence their hard-coded path. Show quoted text
> As for "use warnings" -- even the current manpage says "use warnings" > is preferred over "-w" (from https://perldoc.perl.org/warnings.html): > > > What's wrong with -w and $^W > > Although very useful, the big problem with using -w on the command > line to enable > warnings is that it is all or nothing. Take the typical scenario when > you are writing > a Perl program. Parts of the code you will write yourself, but it's > very likely that > you will make use of pre-written Perl modules. If you use the -w flag > in this case, > you end up enabling warnings in pieces of code that you haven't > written. > > > > Having a module that supports or allows itself to be run with "-w", is > different than enforcing it for perl. While users may use "-w" for > simplicity, a module released on CPAN shouldn't use it because it > either 1) will turn on warnings where modules don't expect them to be > on, or 2) won't turn on warnings for the module using "-w", as "use > warnings" should have been used to turn on warnings for that module. > > I'm not sure that Build is the right place to enforce allowing "-w" on > the perl invocation line for the rest of the perl ecosystem.
It's not about -w, it's about allowing a command line argument to the perl executable. That also includes -T for example. Closing as WONTFIX. Leon
From: cpan [...] tlinx.org
Am I supposed to be able to reply to the bugmail and have the reply be appended to the bug? I sent the following but noticed it wasn't in the bug nor responded to. Is that a bug in the bug-handling system? Thanks! -linda Show quoted text
-------- Original Message -------- Subject: Re: [rt.cpan.org #123217] test failure Date: Wed, 11 Oct 2017 00:22:21 -0700 From: cpan@tlinx.org To: bug-ExtUtils-Helpers@rt.cpan.org References: <RT-Ticket-123217@rt.cpan.org> <rt-4.0.18-22470-1507438376-1713.123217-4-0@rt.cpan.org> <CAHhgV8hF1670xn_tzBi24+sndEjVwgN1UB2QgXV2yc2KVs4CVQ@mail.gmail.com> <rt-4.0.18-24049-1507534341-1781.123217-5-0@rt.cpan.org> <rt-4.0.18-15097-1507547768-219.123217-5-0@rt.cpan.org> <CAHhgV8iqsvZAtVruGK0SPjG++eMaJwtsArSMpuG1oKH+1-DyVg@mail.gmail.com> <rt-4.0.18-6039-1507564591-1517.123217-6-0@rt.cpan.org> <rt-4.0.18-23247-1507567842-1014.123217-6-0@rt.cpan.org> <rt-4.0.18-16650-1507642234-1105.123217-6-0@rt.cpan.org> Leon Timmermans via RT wrote: ....
> None of those recommend modifying the value for startperl. None. >
I'm not sure what startperl is -- It asked what I wanted to put in the 1st line of programs during configuration, to start perl. Is that the value you are referring to? Are you saying that the perl configuration process shouldn't ask for a value there, because no value other than the default will work?
Subject: Re: [rt.cpan.org #123217] test failure
Date: Wed, 11 Oct 2017 00:22:21 -0700
To: bug-ExtUtils-Helpers [...] rt.cpan.org
From: cpan [...] tlinx.org
Leon Timmermans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=123217 > > > On Mon Oct 09 12:50:42 2017, perl-diddler@tlinx.org wrote: >
>> If you google on /usr/bin/env, you'll find some places, including, >> >> https://unix.stackexchange.com/questions/29608/why-is-it-better-to- >> use-usr-bin-env-name-instead-of-path-to-name-as-my >> >> https://www.cyberciti.biz/tips/finding-bash-perl-python-portably- >> using-env.html >> >> Maybe from perlmonks as well. >>
> > None of those recommend modifying the value for startperl. None. >
I'm not sure what startperl is -- It asked what I wanted to put in the 1st line of programs during configuration, to start perl. Is that the value you are referring to? Are you saying that the perl configuration process shouldn't ask for a value there, because no value other than the default will work?