Re: Testing for non-perl system requirements

All I can do is throw an exception and exit if something is missing, or notify and continue.

What I would do is have the test code check to see if something is missing and then use Test::More's "skip" feature to skip any tests that depend on the feature.

I realize this isn't what you regard as The Right Way, but I think it works tolerably well. I think it would be pretty difficult for the build process to cover every sort of system feature that you might be interested in checking.

(I see that if I have to skip all of the tests, the smoketest machines mail me UNKNOWN messages instead of FAIL... seems reasonable, off hand).

If anyone's interested, I've been writing test code that looks like:

use Test::More;
my $emacs_found = qx{ emacs --version 2>/dev/null };

if( not( $emacs_found ) ) {
  plan skip_all => 'emacs was not found in PATH';
} else {
  plan tests => 27;
}

use_ok( 'Emacs::Run' );

[...]
[download]

Comment on Re: Testing for non-perl system requirements Download Code

Replies are listed 'Best First'.
Re^2: Testing for non-perl system requirements by leocharre (Priest) on Apr 03, 2008 at 17:12 UTC
Hahahah.. yeah.. you sly dog you... that's very tempting :-) But it will blow up on non unixy systems, right? If so, you should bail out unless the os is all good. Unless you don't care about those systems, but then you get ugly test reports. I think I'm having feelings for Devel::AssertOS , it has a cli tool to embed the junk in your distro very quickly. I find it ingenious. It just adds some inc stuff into your distro, appends the MANIFEST, and prepends the Makefil.PL with `use lib inc; use Devel::AssertOS qw(Unix Otherstuffyoutellit);` I suppose after that we can go ahead and do whatever.. invoke external bash scripts.. backtick.. etc. Some systems might have security features to disable a cpan install from making command calls ???	[reply] [d/l]
Re^3: Testing for non-perl system requirements by doom (Deacon) on Apr 03, 2008 at 22:13 UTC
But it will blow up on non unixy systems, right? If so, you should bail out unless the os is all good. Unless you don't care about those systems, but then you get ugly test reports. Actually, I'm not sure about how big an issue this is at this point. Most of the "windows" boxes that perl runs on are likely to really be "cygwin", and MacOS is essentially the latest proprietary fork of the BSD codebase. As far as smoketest messages go, I'm sorting through too many other ugly messages to even notice if there's a VMS system out there complaining about something. (Though it occurs to me now that I write this that I should really be trapping any errors on that qx, and also skipping the tests if it blows up. Easy enough.) Still, I'll take a look at Devel::AssertOS... the last time I tried to think about issues like this was some years ago, and there definitely seemed to be some missing pieces in the story. Like, you could check $^O, but you had to parse the results yourself, and you needed to watch out for gotchas (e.g. you can't just match for "win" if you want to skip windows boxes, because that'll also hit other things like "cygwin"... so you might, wonder, what's the definitive list of all possible returns from $^O? Last I looked, there didn't seem to be one...).	[reply]
Re^4: Testing for non-perl system requirements by Intrepid (Curate) on Apr 08, 2008 at 15:55 UTC
Most of the "windows" boxes that perl runs on are likely to really be "cygwin" [...] It's a small statement made in a large discussion but it still, IMHO, bears correcting. This isn't true, and I wonder how the poster (doom) came up with such a contention. I don't have any knowledge of a place to find statistics, but I think most Monks and others who know Perl on MS Windows for the length of time I have, will agree that the number of cygwin perl installs vs the number of ActiveState Perl installations is most likely vanishingly small. As for StrawberryPerl, it is very new as well as being a small project compared to the big-time corporate smell of ActivePerl. Those who want to be fanbois instead of discussing facts can just `>/dev/null` as far as I am concerned. Facts is facts. ;-) Soren A / somian / perlspinr / Intrepid	[reply]
Re^4: Testing for non-perl system requirements by mr_mischief (Monsignor) on Apr 08, 2008 at 04:59 UTC
Honestly, with Strawberry Perl, the only reason to install Cygwin is if you're needing it for something else anyway. Strawberry provides a good Perl, CPAN, and gcc environment for Windows that just works. There might be a few problem modules here and there, but the situation is much better than ActiveState's perl and takes much less space than Cygwin. Also, with most machines readily having the CPU speed and memory to handle a virtual hardware machine or hypervisor, the best solution for Windows and a Unix on the same box turns out for many people to actually be Windows and a Unix running on the same box together. That means if I need good Unix-like behavior but can't give up Windows, I'm likely to set up a Windows VM on top of Linux or OS X. Some will do the opposite. Cygwin and Wine still have their place, but they are not as important as they once were.	[reply]