On Thu, 15 Sep 2005, H.Merijn Brand wrote:
> On Thu, 15 Sep 2005 09:48:18 -0400 (EDT), Andy Dougherty
> <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 15 Sep 2005, H.Merijn Brand wrote:
> >
> > > > > lib/ExtUtils/t/Constant...................Can't exec "gmake": No such
> > > > > file or di rectory at ../lib/ExtUtils/t/Constant.t line 130.
> > > > > FAILED at test 3
> >
> > > On Wed, 14 Sep 2005 12:57:16 -0700, "Sharma, Rahul" <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Is there any alternative for gmake utility. It is not installed on our
> > > > servers.
> > >
> > > Which makes it even more weird.
> > >
> > > So, Configure is right in detecting 'make', but somehow EU::C still wants
> > > 'gmake', which is obviously wrong.
> >
> > Actually, we don't know what Configure detected. Both the 'make' and
> > 'gmake' variables are used internally by Configure, but are reset at the
> > end to plain values of 'make' and 'gmake' respectively, and are not
> > useful.
> >
> > > Even though I must confess that HP's make sucks compared to gmake, which
> > > is my default make on all my HP-UX machines, this obviously is a bug.
> > >
> > > I did a scan on a *clean* source tree, but found no indication of where
> > > 'gmake' might be introduced after Configure used 'make'
> >
> > I can think of two possibilities offhand: Does the user have an
> > environment variable set that might lead to this? Alternatively, did
>
> Very unlikely, since he states that gmake is not available on his system
Well, there is the line
$make = $ENV{MAKE} if exists $ENV{MAKE}
in lib/ExtUtils/t/Constant.t, which could be the culprit even if the
gmake executable isn't installed. Explicitly doing
unsetenv MAKE
(or whatever the equivalent is for his shell) might work.
> > the previously-installed perl (/usr/bin/perl) use gmake?
>
> Ahh, didn't think of that. Yes, very possible.
> Do you think that
>
> # sh Configure -Dinc_version_list=none ...
>
> would be enough to prevent that?
Probably not. The test does the usual dance
if( $ENV{PERL_CORE} ) {
chdir 't' if -d 't';
@INC = '../lib';
}
to set @INC. I had been wondering about shared libraries, but this
case doesn't involve shared a libperl.
If it's not the environment variable, then perhaps it's a problem
with $^X. The test does:
$^X = $perl;
my $lib = $ENV{PERL_CORE} ? '../../../lib' : '../../blib/lib';
my $runperl = "$perl \"-I$lib\"";
print "# perl=$perl\n";
and I do recall that we've had some problems getting $^X right in all
cases.
The next diagnostic step is to run the test verbosely:
cd t
echo $MAKE
./perl harness -v ../lib/ExtUtils/Constant.t
and look at the # make = $make and # perl=$perl lines to see
what's really getting called.
--
Andy Dougherty [EMAIL PROTECTED]
