Re: help with report 4566036 on PDL-2.4.4_05
Bob Walker
> Dear Bob Walker,
>
> Thanks for participating in CPAN Testing. I'm
> investigating your recent test report:
>
> http://nntp.x.perl.org/group/perl.cpan.testers/4566036
>
> to determine how to fix the problem. It looks
> like the there may be some skew between the perl
> that is being used to run the tests located in
>
> /export/home/bob/cpantesting/perl-5.10.0/bin/perl
>
> and the version being run by the podselect command.
>
> Is there any reason why the directory containing the
> $^X perl (/export/home/bob/cpantesting/perl-5.10.0/bin)
> is not in the PATH?
>
There is no reason (well apart from never thinking to do it(althogh
having thought about it there is a reason(nothing which rewriting my
script wouldnt fix))).
I think assuming PATH being correct may be a bad assumption. How you
overcome this I dont know.
> If you prepend it to the PATH, does the automated test
> then run?
>
It would seem it does. There should be a pass winging its way to the
internet right now.
Im ccing this to the the cpan-testers-discuss mailing list. In case they
have any thoughts or suggestions.
--
Bob Walker
http://london.randomness.org.uk - http://tech.randomness.org.uk
http://londonstairs.co.uk - http://londonjoinery.com
Stairs and doors are obstacles to overcome on the way to ale and food
David Cantrell
> On Sun, 12 Jul 2009, Chris Marshall wrote:
> >Is there any reason why the directory containing the
> >$^X perl (/export/home/bob/cpantesting/perl-5.10.0/bin)
> >is not in the PATH?
> overcome this I dont know.
Indeed, it is quite common for $^X to not be in the path. For example,
large applications which use perl often have their own build of perl
with its own install of libraries from the CPAN.
--
David Cantrell | Godless Liberal Elitist
I caught myself pulling grey hairs out of my beard.
I'm definitely not going grey, but I am going vain.
David Golden
> On Sun, Jul 12, 2009 at 11:55:57PM +0100, Bob Walker wrote:
> > On Sun, 12 Jul 2009, Chris Marshall wrote:
> > >Is there any reason why the directory containing the
> > >$^X perl (/export/home/bob/cpantesting/perl-5.10.0/bin)
> > >is not in the PATH?
> > I think assuming PATH being correct may be a bad assumption. How you
> > overcome this I dont know.
>
> Indeed, it is quite common for $^X to not be in the path. For example,
> large applications which use perl often have their own build of perl
> with its own install of libraries from the CPAN.
>
Another example would be systems with a vendor supplied perl and a user's
locally-compiled perl. This might be a desktop machine or might be a web
hosting service.
There's no way to know which perl appears first in PATH and scripts can run
against either directly from the command line or through a shebang line.
If you really want to run a utility installed with the currently executing
perl, you might be best off doing something like this:
use File::Spec::Functions 'catfile';
use File::Basename 'dir_name';
use IPC::Cmd 'can_run';
my $binary = can_run( catfile( dirname($^X), 'podselect' ) );
can_run() will sort out file name extensions like ".exe" or ".bat" on
Windows, which is why that extra step is necessary.
-- David
Chris Marshall
> On Sun, Jul 12, 2009 at 11:55:57PM +0100, Bob Walker wrote:
>> On Sun, 12 Jul 2009, Chris Marshall wrote:
>>> Is there any reason why the directory containing the
>>> $^X perl (/export/home/bob/cpantesting/perl-5.10.0/bin)
>>> is not in the PATH?
>> I think assuming PATH being correct may be a bad assumption. How you
>> overcome this I dont know.
>
> Indeed, it is quite common for $^X to not be in the path. For example,
> large applications which use perl often have their own build of perl
> with its own install of libraries from the CPAN.
Any suggestions for how to work around the problem?
The initial problem I was trying to resolve was
failure of podselect to compile since Devel::Autoflush
was not available. Unsetting PERL5OPT on the podselect
line was a hack to resolve the problem but I couldn't
think of a better way to do it. Apparently, there is
no way to override PERL5OPT usage....
Have other modules/module authors had this problem with
podselect and other perl scripts being called from the
shell within make?
--Chris
David Golden
> Any suggestions for how to work around the problem?
>
See my other email.
The initial problem I was trying to resolve was
> failure of podselect to compile since Devel::Autoflush
> was not available. Unsetting PERL5OPT on the podselect
> line was a hack to resolve the problem but I couldn't
> think of a better way to do it. Apparently, there is
> no way to override PERL5OPT usage....
>
There was an unfortunate period of time when Devel::Autoflush in PERL5OPT
caused a lot of problems. Recent smokers now only use Devel::Autoflush
during Makefile.PL/Build.PL and go out of their way to make sure it's found,
even if someone invokes a different perl than the one running tests.
However, if you want to clear out PERL5OPT, you can just put "local
$ENV{PERL5OPT};" before your system calls. That will be more portable than
trying to unset it on the command line.
> Have other modules/module authors had this problem with
> podselect and other perl scripts being called from the
> shell within make?
>
Possibly, but if they complained, it never made it to cpan-testers-discuss
whre we could suggest an answer. :-) (Thank you Bob, for fowarding Chris'
question)
-- David
Chris Marshall
and testing new PDL's with pre-existing PDL versions in
the @INC path.
This happens when submodules PDL::A, PDL::B, and PDL::C are
installed already in @INC somewhere. Then a new PDL is
built configured (manually or automatically) to build
PDL::A and PDL::C only (not PDL::B).
The tests for PDL::B then fail because of version skew
with the pre-existing PDL::B when in fact PDL::B was not
even built and should not be tested against.
We're thinking to implement a check for a pre-existing
PDL to adjust the testing parameters.
Have other modules experienced this type of problems
and if so, how did you resolve them?
Thanks much,
Chris Marshall for the PDL Developers