On 10/21/07, demerphq <[EMAIL PROTECTED]> wrote:
> B) Absent a documented way to set this in MakeMaker, suggesting that
> it is the appropriate solution to the problem intended to be solved by
> Devel::CheckLib seems out of place at best, and presumptive at worst.
>
> As an aside, it seems to me that both Devel::CheckLib and
> configure_requires suffer from a fatal flaw in that they do not solve
> the problem for existing modules. The solution to this problem lies in
> better logic in CPAN Testers. What that logic should be is left as an
The more important words in these paragraphs above are these: "the problem".
"The problem" is not well defined or perceived the same by everyone.
At the core CPAN Testers provides a means to capture the experience of
users attempting to build and test a module. As I see it, the root of
"the problem" is that there are many ways for things to fail, and
authors tend to object to getting "FAIL" grades (in big capital
letters) for things outside their control.
Authors complain to CPAN Testers, testers complain to those who write
CPAN Testers clients about getting complaints for authors. The
investment of time and energy to improve CPAN Testers clients is
weighed against the annoyance of getting complaints.
So, gradually, the more easily determined failure paths have being
pruned out to just cut down on the noise. Ones that are easy to
automate have been -- e.g. prerequisite failures are now just
discarded (at least by CPAN::Reporter).
Harder failure paths to determine -- such as unsupported operating
systems -- have been addressed by special key words ("OS Unsupported"
or "No support for OS") to let authors abort building or testing with
an NA report. But apparently that's too hard or too obscure for some
-- thus Devel::CheckOS.
Confirming a working compiler setup and appropriate libraries is an
even tougher problem for authors, and the method for signaling it is
even more obscure. ("exit 0" before creating a Makefile.) And thus
there is Devel::CheckLib.
I'm not interested in spending my time writing an omniscient failure
detection tool. I'm not interested in trying to solve "the problem"
(many ways for things to fail and authors affronted by FAIL reports)
for all of CPAN.
I'm am willing to invest my time in making it easier for authors to do
something about being annoyed by FAIL reports from missing libraries.
And I'm willing to invest my time to have something more constructive
to say in response to complains. ("You're right that this is a library
problem -- go use Devel::CheckLib and you won't get these FAIL
reports"). That is "the problem" that Devel::CheckLib is trying to
solve.
David
