develooper Front page | perl.perl5.porters | Postings from July 2005

[perl #36542] Re: [Module::Build] Edge cases in "find_perl" algorithms

From:
Ken Williams
Date:
July 14, 2005 08:27
Subject:
[perl #36542] Re: [Module::Build] Edge cases in "find_perl" algorithms
Message ID:
rt-3.0.11-36542-117264.5.13954211151422@perl.org
# New Ticket Created by  Ken Williams 
# Please include the string:  [perl #36542]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36542 >


Hi Schwern,

That's good analysis, but I don't actually think anything should be 
changed in Module::Build's method until we can demonstrate a case in 
which it fails, and right now I know of none.  Since it checks 
Config::myconfig(), it ensures that the version and any compilation 
options are correct.

Perhaps it could also check a variable like $Config{installarchlib} or 
something, to make sure we've got the right library path, in case the 
crazy user has two exactly identically-configured perls installed in 
two different places we happen to find with the search algorithm.

On Jul 13, 2005, at 5:41 PM, Michael G Schwern wrote:
>
> CPAN.pm makes the
> mistake of always looking for $^X in the cwd.  This means it can get 
> the
> following wrong:
>
> 	$ ls ./perl
> 	./perl
> 	$ perl -MCPAN -e shell
>
> $^X will be "perl".  It will look for "$cwd/perl" and find the one in 
> the
> cwd rather than perform a PATH search.
>
> MakeMaker, CPANPLUS and Module::Build do not handle this case at all, 
> they do
> not look in the cwd.  In this case MakeMaker and CPANPLUS will use the
> relative $^X, which is dangerous because it will go wrong as soon as
> something chdirs.

Regarding the current-working directory inspection, it seems to me that 
we shouldn't check there unless the CWD is in the PATH.  Which M::B 
currently does.

  -Ken




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About