in reply to Re: Building Win32::GuiTest for perl 5.14 or higher
in thread Building Win32::GuiTest for perl 5.14 or higher

the answer is yes.

Don't you find it a little suspicious that an XS based module with total dependency upon the Windows OS architecture and APis is so successful in building on Linux, Solaris, BSD et al?

I suspect this is a more meaningful source.

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?
  • Comment on Re^2: Building Win32::GuiTest for perl 5.14 or higher (Bad tests == useless statistics!)

Replies are listed 'Best First'.
Re^3: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!)
by davido (Cardinal) on Jun 25, 2012 at 19:19 UTC

    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

[reply]
[d/l]
[select]

      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]
      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]

In Section Seekers of Perl Wisdom