Mailing List Archive

gdbm.t
The file t/lib/gdbm.t assumes that GDBM_File was built as a distributed
extension. But some of us prefer to build GDBM_File as an add-on extension,
which means it won't be in Config.pm and so gdbm.t won't run. I know this
has been mentioned here a few times. This patch is intended to address this
issue.

I've taken a few guesses here that are worth discussing. I unshift '../lib'
into @INC rather than wiping out all of @INC. Maybe it should add ./blib or
../blib if it exists?

Dean


*** t/lib/gdbm.t Tue Oct 18 11:44:13 1994
--- ../patches/gdbm.t Mon Sep 11 15:56:54 1995
***************
*** 3,17 ****
# $RCSfile: dbm.t,v $$Revision: 4.1 $$Date: 92/08/07 18:27:43 $

BEGIN {
! @INC = '../lib';
! require Config; import Config;
! if ($Config{'extensions'} !~ /\bGDBM_File\b/) {
! print "1..0\n";
! exit 0;
! }
}
-
- use GDBM_File;

print "1..12\n";

--- 3,17 ----
# $RCSfile: dbm.t,v $$Revision: 4.1 $$Date: 92/08/07 18:27:43 $

BEGIN {
! chdir 't' if -d 't';
! unshift @INC, '../lib';
! eval { require GDBM_File };
! if( $@ ){
! print "1..0\n";
! exit 0;
! }
! import GDBM_File;
}

print "1..12\n";
Re: gdbm.t [ In reply to ]
On Mon, 11 Sep 1995, Dean Roehrich wrote:

> The file t/lib/gdbm.t assumes that GDBM_File was built as a distributed
> extension. But some of us prefer to build GDBM_File as an add-on extension,
> which means it won't be in Config.pm and so gdbm.t won't run. I know this
> has been mentioned here a few times. This patch is intended to address this
> issue.
>
> I've taken a few guesses here that are worth discussing. I unshift '../lib'
> into @INC rather than wiping out all of @INC. Maybe it should add ./blib or
> ../blib if it exists?

I think I'd prefer to leave the t/lib/?db*.t tests alone and give
GDBM_File (and DB_File) get their own t/ subdirectories instead. That
way, if you're adding GDBM_File later, you treat it like any other extra
extension. I don't know if this would actually work right now, but it
seems a reasonable way to go to me.

The reason we wipe out @INC rather than just prepend to it is so that we
are sure we are testing *this* installation of perl5 rather than some
previously installed version. I think that's a genuinely useful thing
to do. It just occured to me that folks can still spoof it with the
environment variable PERL5LIB, but that probably doesn't happen too
often.

Andy Dougherty doughera@lafcol.lafayette.edu
Re: gdbm.t [ In reply to ]
On Mon, 11 Sep 1995, Dean Roehrich wrote:

> The file t/lib/gdbm.t assumes that GDBM_File was built as a distributed
> extension. But some of us prefer to build GDBM_File as an add-on extension,
> which means it won't be in Config.pm and so gdbm.t won't run. I know this
> has been mentioned here a few times. This patch is intended to address this
> issue.
>
> I've taken a few guesses here that are worth discussing. I unshift '../lib'
> into @INC rather than wiping out all of @INC. Maybe it should add ./blib or
> ../blib if it exists?

I think I'd prefer to leave the t/lib/?db*.t tests alone and give
GDBM_File (and DB_File) get their own t/ subdirectories instead. That
way, if you're adding GDBM_File later, you treat it like any other extra
extension. I don't know if this would actually work right now, but it
seems a reasonable way to go to me.

The reason we wipe out @INC rather than just prepend to it is so that we
are sure we are testing *this* installation of perl5 rather than some
previously installed version. I think that's a genuinely useful thing
to do. It just occured to me that folks can still spoof it with the
environment variable PERL5LIB, but that probably doesn't happen too
often.

Andy Dougherty doughera@lafcol.lafayette.edu
Re: gdbm.t [ In reply to ]
Excerpts from the mail message of Andy Dougherty:
) The reason we wipe out @INC rather than just prepend to it is so that we
) are sure we are testing *this* installation of perl5 rather than some
) previously installed version. I think that's a genuinely useful thing
) to do. It just occured to me that folks can still spoof it with the
) environment variable PERL5LIB, but that probably doesn't happen too
) often.

That happened to me just last night (PERLLIB also breaks it) so I'm
looking at addressing this.

--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)