Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Detecting a running ToolServer?

1 view
Skip to first unread message

Michael G Schwern

unread,
Nov 28, 2002, 5:19:20 PM11/28/02
to macperl...@perl.org
I'd like either Test::Harness or Module::Build (not sure which) to try to
figure out if `$^X ...` is going to work on MacPerl so it can warn the user
that 'Build test' isn't going to work rather than simply vomit when it tries
to run the tests. So is there a way to determine if ToolServer is running?
Or should I just do a `$^X -e 'print "Test"'` probe?


--

Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
It wasn't false, just differently truthful.
-- Abhijit Menon-Sen in <2001110818...@lustre.dyn.wiw.org>

Chris Nandor

unread,
Dec 1, 2002, 10:12:43 PM12/1/02
to Michael G Schwern, macperl...@perl.org
At 14:19 -0800 2002.11.28, Michael G Schwern wrote:
>I'd like either Test::Harness or Module::Build (not sure which) to try to
>figure out if `$^X ...` is going to work on MacPerl so it can warn the user
>that 'Build test' isn't going to work rather than simply vomit when it tries
>to run the tests. So is there a way to determine if ToolServer is running?
>Or should I just do a `$^X -e 'print "Test"'` probe?

You can do:

use Mac::MoreFiles;
print $Application{MPSX}; # MPSX == ToolServer creator code

That gives the path to ToolServer, or undef if no ToolServer. However,
that doesn't tell you if ToolServer is configured properly, or if perl is
available to it.

I might recommend instead:

$can_do = `which perl \xB3 Dev:Null`; # \xB3 is the STDERR redirect

It will return the path to the perl executable if ToolServer is available
*and* perl is available. It will return undef or the empty string
otherwise. But the probe you mention should be fine, too.


* Note that under the MacPerl app, $^X eq "MacPerl", so it cannot be used
to invoke perl under ToolServer. You just need to use "perl" and hope the
user didn't change the name of the perl tool for MPW. Maybe do:

my $exe;
for ($^X, 'perl') {
$exe = $_, last if `which $_`; # or print "Test" probe ...
}

The perl test suite etc. doesn't need to care about the MacPerl app, only
the perl tool, but if you are looking to make modules installable via a
generic interface for MacPerl users, it should be able to work from the
MacPerl app, and without ToolServer, else it won't really help much, since
most users won't have ToolServer, let alone MPW.


Hope that helps; let me know if you need more information.

--
Chris Nandor pu...@pobox.com http://pudge.net/
Open Source Development Network pu...@osdn.com http://osdn.com/

Michael G Schwern

unread,
Dec 2, 2002, 4:29:25 AM12/2/02
to Chris Nandor, macperl...@perl.org
On Sun, Dec 01, 2002 at 10:12:43PM -0500, Chris Nandor wrote:
> The perl test suite etc. doesn't need to care about the MacPerl app, only
> the perl tool, but if you are looking to make modules installable via a
> generic interface for MacPerl users, it should be able to work from the
> MacPerl app, and without ToolServer, else it won't really help much, since
> most users won't have ToolServer, let alone MPW.

This is for Module::Build's test target which uses Test::Harness which runs
each perl test program in a seperate process. AFAIK there's just no way
to do that on MacPerl without ToolServer and I can't think of another way to
run tests.

Except for a crazy idea. Write an AppleScript program which acts like
Test::Harness. Have that run each perl program in turn and interpret the
output. ./Build test then just calls that AppleScript program and quits (or
the AppleScript quits any running MacPerl before trying to run the tests).

Is it just stupid enough to work?


--

Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One

Follow me to certain death!
http://www.unamerican.com/

0 new messages