[Module::Build] Re: [PATCH] add Module::Build 0.27_08

[Randy W. S. <ml...@th...>]

Yitzchak Scott-Thoennes wrote:
> On Tue, Mar 07, 2006 at 11:59:17AM -0500, Randy W. Sims wrote:
> 
>>Ah, this is because we don't expect to be run from a non-installed perl. 
>>Notice we pretty much throw $^X away if it's not absolute? Is there any 
>>reason we can't add:
>>
>>  return $^X if $proto->_perl_is_same($^X);
>>
>>at the top of find_perl_interpreter(). Or do we need to be more guarded?
>>
>>Randy.
> 
> 
> It looks like find_perl_interpreter is supposed to return an absolute
> path, so my similar suggestion does that.  Do you know how the return
> value is used?

The $perl returned from find_perl_interpreter() ?

It's used in a number of places:

When you run Build.PL, it's stored so that invokations of ./Build use 
the same $perl.

If you run Build.PL and the /some/perl Build it checks if it's the same 
perl, ala the _perl_is_same() method.

It's used when running self-expanding files (or whatever they're 
called), eg 'My-Distro/lib/My/Distro.pm.PL'

It's used to grab the default, unaltered @INC (@inc = `$perl -le "print 
for \@INC"`)

Workaround a Test::Harness bug that "loses the correct perl we're 
running under"


*** I /think/ I see several possible problems here ***
fix_shebang_line() # adapted from MakeMaker


Anything that calls run_perl_script(), eg ./Build disttest emulates a 
user running through the build process.

Running xsubpp, when ExtUtils::ParseXS is not installed.

run_perl_script & run_perl_command are used several times in various tests.


Oh, did you want a thorough answer?

Randy.