in reply to Odd test report, how to address?

I just looked at the full cpantesters report for your module, and this appears to be the only failure. If Xcode is connected to your module somehow, then you might consider wrapping a test in such a way that it can control a SKIP block unless the whole package would depend on it.

If on the other hand Xcode has nothing to do with your module (and I am under the impression it doesn't) then I don't see why you can't safely ignore this particular FAIL result, especially as there are four other 'darwin' versions reporting a PASS for you. Maybe an entry in the README file or a note in the POD would suffice.

I don't think you would be wrong to follow up with the tester, but as you suggest, it might be an interesting exercise in diplomacy. :)

The answer to the question "Can we do this?" is always an emphatic "Yes!" Just give me enough time and money.

Replies are listed 'Best First'.
Re^2: Odd test report, how to address?
by einhverfr (Friar) on Nov 13, 2013 at 04:20 UTC
    This isn't even getting to the test case. This is happening when running the make, and Xcode isn't directly used by the module, or indirectly as far as I can tell. As far as I was able to find, this was an issue with "make" being a utility from apple that hadn't been configured yet which is why I figured I might want to follow up...
[reply]

      Given that is the case, then I would definitely go with a note in README and then follow up with the tester. It might be possible to test for this in Makefile.pl before make is ever called, but why bother in an automated environment? It will still be reported as a FAIL.

      The answer to the question "Can we do this?" is always an emphatic "Yes!" Just give me enough time and money.
[reply]
[d/l]
        Yeah. I did try to follow up with the tester but the mail bounced. Heh..... I don't like this because it means that these are like ignored warnings....
[reply]

In Section Seekers of Perl Wisdom