On Fri, Jul 1, 2011 at 4:23 PM, David Cantrell <da...@cantrell.org.uk> wrote:
> On Fri, Jul 01, 2011 at 03:11:08PM +0300, Gabor Szabo wrote:
>
>> So I'd like to ask you all to check the test reports of your modules and if
>> you
>> have consistent failures of one of your modules on Windows then try to fix
>> them.
>> If you need any help, please send a message on either of those mailing list
>> asking people how to fix specific Windows related issues.
>
> I went through a period of trying to make sure my code worked on
> Windows, but I've given up. Not because it's hard to do - it generally
> isn't - but the complete lack of a reasonable set of tools* on Windows,
> which just makes me angry whenever I have to touch the blasted thing,
> made me stop.
Indeed the issues I encountered were all quite simple:
1) This code in test:
`date > file`
On Windows the date command waits for input so this got the test stuck.
Probably many testers just put this module in the disabled list so it
will be never tested.
2) the separator of PATH is not : on Windows so this code:
$ENV{PATH} = 'mypath' . ':' . $ENV{PATH}
is incorrect. I think the right approach is to
use Config;
$ENV{PATH} = 'mypath' . $config{} . $ENV{PATH}
3) running external perl scripts
Code like this (in a test)
`path/to/other/perl/script param param`
is not a good idea on Linux either as this will use the perl in the sh-bang
instead of the "current" perl which is running the tests.
These might be different version of Perl.
Besides, on Windows the above to work needs special configuration that not
all the Perl installers provide. The better approach is to write:
`$^X path/to/other/perl/script param param`
Though I really prefer
qx{$^X path/to/other/perl/script param param}
Thank you for you consideration of the other 80% of people who are
still using Windows.
regards
Gabor
