in reply to Re^2: Building Win32::GuiTest for perl 5.14 or higher (Bad tests == useless statistics!)
in thread Building Win32::GuiTest for perl 5.14 or higher

Another "yes." :)

The test suite uses a lot of SKIP blocks if the OS isn't reported as win32 or cygwin, so it's issuing false positives for Linux. The author should bail out (or possibly die at Makefile.PL stage) if Win32/cygwin isn't available. That would prevent false positives, while simultaneously preventing a bunch of FAILs from cluttering the results.

In particular, this line from Makefile.PL should be elevated to fatal: 

warn "** This module can only work under Win32\n" unless $can_compile;

[download]

The author might also have better results at portability across win32 platforms if he used ExtUtils::CppGuess to detect the correct compiler to use and the appropriate linker libraries. I've spent some time looking over that module and consider it pretty solid. A lot of work has gone into making that module "do the right thing."

But nevertheless there is still a Win32 "PASS" at the 5.14.2 level using Strawberry Perl, both with 32 bit and 64 bit Perls.

Nice PPM status source. I like that.

This might be helpful: RT#75338 suggests forcing the build.

Updated: Added a look at Makefile.PL and EU::CppGuess.

Dave

Replies are listed 'Best First'.
Re^4: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!)
by cavac (Prior) on Jun 25, 2012 at 20:22 UTC

    The author should bail out (or possibly die at Makefile.PL stage) if Win32/cygwin isn't available.

    Yes. And no. I myself have a few Windows- or Linux-only modules in my DarkPan repo. Mostly, they come in pairs (same external API, but completly different internals). Instead of failing to build on the "wrong" OS, they build as "hollow shells" without functionality (except to die() when new() is called.

    Doing it this way makes coding project that depend on a huge number of modules easier. You just pull in all your prerequisites (no fiddling around with Makefile.PL) and you can even use them (no more fiddling around with require and eval and stuff). In the main project, i then just have to decide with ones are the ones i instanciate.

    Of course, that's my own special bikeshed color. Yours might vary ;-)

    "You have reached the Monastery. All our helpdesk monks are busy at the moment. Please press "1" to instantly donate 10 currency units for a good cause or press "2" to hang up. Or you can dial "12" to get connected directly to second level support."
[reply]
[d/l]

      Wouldn't it be better to configure the test suite with TODO's, and the incomplete target code with "..." operators instead of polluting the code base with silently-incomplete code?

      I do understand your point though. But it's probably more applicable to the development process than it is to a module uploaded for the world to use on CPAN.


      Dave

[reply]
[d/l]

        I can agree to that. It really depends if it's mostly an internal process streamlined for fast development (often enough i only have hours to days to come up with a large one-off solution that's running for a limited time and scope). Or if the module is designed for a broad audience.

        What it comes down to, in my mind at least, is that many of those problems could be avoided by an enhanced, clearer syntax for conditionally specifying modules as optional requirements ("i need that or that, but at least one of them") as well as clearer syntax for conditionaly using them in the scripts (best solution would be "try this list of modules in the given order and load the first one you find and tell me which one it was").

        Example: Let's say we have two modules with the same API, but one for Linux/Unix and one for windows, i could them do 

        my $pwmodule = use_first qw[Linux::Power Win32::Power];
my $power = $pwmodule::new();
$power->suspend();

        [download]

        "You have reached the Monastery. All our helpdesk monks are busy at the moment. Please press "1" to instantly donate 10 currency units for a good cause or press "2" to hang up. Or you can dial "12" to get connected directly to second level support."
[reply]
[d/l]
Re^4: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!)
by BrowserUk (Patriarch) on Jun 25, 2012 at 19:31 UTC
    The author should bail out (or possibly die at Makefile.PL stage) if Win32/cygwin isn't available.

    The trouble with that theory is that then, whenever a potential user checks the CPAN Tester grid, it looks to the uninitiated like a bad module because of the preponderance of RED fails. This makes both the module and author look like crap.

    The real failure here is the absence of a "Not applicable" category, which IMO renders the Tester grid worse than worthless. A

    As is, with the ratio of 9:1 against any Win32-only module, authors are faced with either accepting a screen of red when there is nothing wrong, or a screen of green when there might be something wrong. It's a piss poor choice either way.

    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.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?
[reply]

      The CPAN Tester's Module Author's FAQ provides a good suggestion. I was close but this is better:

      "How can I indicate that my distribution only works on a particular operating system?"

      While it isn't a very elegant solution, the recommend approach is to either die in the Makefile.PL or Build.PL (or BAIL_OUT in a test file) with one of the following messages: 

          No support for OS
    OS unsupported

      [download]

      CPAN Testers tools will look for one of those phrases and will send an NA (Not Available) report for that platform.


      Dave

[reply]
[d/l]

        And that is somehow better than assuming the failure of a module named Win32::something from a tester not using that platform is a "Not applicable"?

        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.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?
[reply]

In Section Seekers of Perl Wisdom