in reply to Re: Testing for non-perl system requirements
in thread Testing for non-perl system requirements

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

Replies are listed 'Best First'.
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...).

      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. ;-)

      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.