On Sat, Feb 17, 2007 at 05:10:24PM -0800, Darren Duncan wrote:
> At 9:51 PM +0000 2/17/07, Tim Bunce wrote:
> >On Sat, Feb 17, 2007 at 03:22:14AM -0800, Darren Duncan wrote:
> > > So I updated t/85gofer.t and re-ran 'make test'.
> >>
> >> This time, I just showed the output of testing t/85gofer.t rather
> >> than the whole test suite.
> >>
> > > FYI, the Perl I ran the original DBI Makefile under is 5.8.8 no
> >> threads, installed in a non-standard location (shown in the output
> >> below). My system Perl is 5.8.6 with threads, and I have left it
> >> pristine, except for SVK. So I don't know if the error message is
> >> mentioning 5.8.6 because that's my system perl version or if there is
> >> some other reason.
> >
> >The pipeone (and stream) transports use IPC::Open3 to launch perl in a
> >subprocess that data can be sent to and received from via stdio:
> >
> > perl -MDBI::Gofer::Transport::pipeone -e run_one_stdio
> >
> >To try to make sure the same libs are used by the subprocess, it does this:
> >
> > local $ENV{PERL5LIB} = join ":", @INC;
> >
> >It presumes it'll get the same perl executable because it assumes the
> >perl being used is the first in the PATH.
> >
> >Does that help you shed some light on what's happening?
> >
> >What command did you use to execute Makefile.PL?
>
> This is what I did on my system, after unpacking the DBI archive:
>
> /Volumes/Programming160/perl6 Makefile.PL
Okay. The problem is due to a combination of using a perl that's not
the first one on the PATH, and t/85gofer.t setting PERL5LIB from @INC.
If you changed your PATH when using different a perl
(which I'd highly recommend) then you wouldn't get the problem:
:
connect('transport=pipeone;policy=pedantic;dsn=dbi:DBM:dbm_type=SDBM_File;lockfile=0','',...)
failed: pipeone command failed: Perl lib version (v5.8.8) doesn't match
executable version (v5.8.6) at
/Volumes/Programming160/Perl/perl588_v6/lib/5.8.8/darwin-2level/Config.pm line
46.
And if t/85gofer.t didn't set PERL5LIB from @INC then whatever perl
it used wouldn't pickup potentially incompatible libs.
Having said that, the DBI clearly needs to be less susceptable to this problem.
> FYI, I also develop Pugs with a Perl 5 installed in a custom location
> (called "/Volumes/Programming160/perl58"), in the same way, and its
> build system works just fine despite invoking various external Perl
> processes, and it is just using the custom Perl.
I suspect you've just been lucky, so far, and/or all the code is
carefully using $^X.
> AFAIK, whatever Perl executable one uses when invoking any Makefile.PL
> is the one that should be used by the distro thereafter, and that's
> what usually happens.
That was the original goal but there's a limit to how far that can be achived.
I recall a discussion on perl5-porters some years ago where the final
conclusion was slong the lines of "use perl via PATH to avoid problems".
Anyway, let's try to deal with this situation as best we can for the DBI...
When executing locally we'd like the same perl used so we could use $^X
to refer to the specific perl binary (on platforms that support $^X).
However when using ssh (with the stream transport) we don't want to use
$^X because it's likely that the remote system won't have perl install
in the same location.
For make test we want to ensure that the subprocess is using the same
blib directory as the parent (which is why it currently does
$ENV{PERL5LIB} = join ":", @INC). Doing that is possibly overkill
but it should be harmless _if_ we're actually using the same perl in the
subprocess.
On the other hand, the only real need is to ensure ./blib is included
when testing, and t/85gofer.t could look after that itself.
I've released an RC5 which uses $^X and moves the PERL5LIB setting to
t/85gofer.t, along with some other more minor changes:
http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.54-RC4.tar.gz
Tim.
