|
Re^3: Perl-5.22.1 in ARM system
by syphilis (Archbishop) on Dec 31, 2015 at 23:45 UTC
|
I am wondering/worried if this failure cause any more issue?
You should send an email to perlbug at perl dot org.
Include the test results that you provided in your first post, and also provide the output of perl -V for the offending perl.
That is, in the directory in which you built perl by running 'make', run ./perl -I./lib -V (though the "-I./lib" is perhaps not needed).
That should spit out all of the configuration information that they'll want to see.
In the meantime, *I* would install the perl you've built and see how it goes - you can always overwrite it (or remove it).
ExtUtils::ParseXS has effect only during the building of a perl extension (ie a module that has a C component that needs to be compiled).
In the usual course of running perl scripts, a problem with ExtUtils::ParseXS is not something that's going to jump up and bite you.
If those failures do bite, it will be when you're building a perl extension - in which case the extension might fail to build, or might fail to pass its test suite.
No guarantees, of course ;-)
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
You should send an email to perlbug at perl dot org. Nothing wrong with that
But, here is something else :)
perl 5.22.1 comes with ExtUtils::ParseXS version 3.28
This version isn't available on CPAN /standalone, it was never uploaded
The latest version on CPAN is 3.30
OP can always get the latest from cpan, get SMUELLER / ExtUtils-ParseXS-3.30
| [reply] |
Re^3: Perl-5.22.1 in ARM system
by Anonymous Monk on Dec 31, 2015 at 09:42 UTC
|
:) Thanks for the reply. I am wondering/worried if this failure cause any more issue?
Issues with what?
No, your computer will not explode if a test fails
Its like you're assembling a bicycle, and you're missing a sticker/decal... -- explosion is imminent
There are 2 to 3 thousand test files ... and each does many tests ... so how many failed out of how many?
| [reply] |
|
|
The above is terrible advice.
The tests are there for a reason: to alert you to problems or potential problems. While it is true that you can install and use modules when not all their tests pass, how will you know which test failures are safe to ignore?
First you should investigate which test (s) is/are failing, then look at them to see what the significance is. Observe the log and then when you see a test reported as failing, go right to that test file and run it again, with the verbose flag, and see what it says as output. If that doesn't enlighten you, read the source for the test. If you don't get it, post a question on the module's support page. After one of these steps maybe you'll be able to conclude that the test is not that important and you can install the module anyway. Or, maybe you'll see that your system is incompatible with the version you are installing, or there's a missing linked C library or something like that.
But simply to ignore test failures while building software, because there are just a few of them or for any other reason, is just completely stupid.
The way forward always starts with a minimal test.
| [reply]
[d/l] |
|
|
And yet, totally expedient when it comes to Perl.
Not one version of perl I've built in the last 15 years has EVER compiled clean. Never. If I (and others) didn't 'ignore' those failures, we'd never have used perl.
As for investigating and reporting them; that's pointless also. The same test failures have been reported ad nauseum; but unless they also fail on *nix; nothing ever changes.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
Re^4: Perl-5.22.1 in ARM system (Ignoring test failures is stupid) by 1nickt
The above is terrible advice... If you don't get it, post a question on the module's support page.... how will you know which test failures are safe to ignore? ... But simply to ignore test failures while building software, because there are just a few of them or for any other reason, is just completely stupid.
Did you investigate this failure 1nickt?
How many core XS modules are there?
Don't you think if this failure was important, that some others tests from those other XS module would fail?
| [reply] |