:) Thanks for the reply. I am wondering/worried if this failure cause any more issue? | [reply] |
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] |
:) 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] |
