Lea Wiemann <lewiemann@xxxxxxxxx> writes:
> From: Lea Wiemann <lewiemann@xxxxxxxxx>
>
> By setting PERL5LIB for the tests, we enable Perl test scripts to just
> say "use Git;" without adding the GITPERLLIB paths to @INC beforehand.
>
> Also, unset GITPERLLIB so that user-set paths in GETPERLLIB don't
> cause the wrong module to be loaded.
>
> Signed-off-by: Lea Wiemann <LeWiemann@xxxxxxxxx>
> ---
> Added since v1: Unset GITPERLLIB.
This goes even further in the opposite direction from the original. It
looks cleaner, and I'd prefer the approach _if_ it worked.
But I do not think it does.
I think the reason we did not do this long time ago in 6fcca93 (Use
$GITPERLLIB instead of $RUNNING_GIT_TESTS and centralize @INC munging,
2006-07-03) was because of the precedence between "use lib @these_paths"
and $PERL5LIB does not work the way you seem to think it does.
If you say in your script:
use lib '/usr/local/git/perl'
use Git;
(and we do want to say so in our script to make sure that people can
install Git.pm outside of system install paths), running the script with
PERL5LIB set to elsewhere that has Git.pm would not help.
I just tried:
$ pwd
/net/knick/home/junio/junk/
$ cat j.perl
#!/usr/bin/perl -w
use lib '/net/knick/home/junio/junk/1dir';
use G;
print $G::it;
$ cat 1dir/G.pm
package G;
our $it = 1;
1;
$ cat 2dir/G.pm
package G;
our $it = 2;
1;
$ perl -w j.perl
1
$ PERL5LIB=/net/knick/home/junio/junk/2dir perl -w j.perl
1
Because "t/t9700/<many>.perl" will _not_ be installed anyway, I do not
think they need to be "built" like the scripted Porcelain commands. If
they unconditionally do "use lib $ENV{GITPERLLIB};" upfront, wouldn't that
be enough to guarantee that you would use the freshly built one during the
test, not the instsalled one?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
