On Thu, Oct 30, 2003 at 11:53:18AM -0800, Stas Bekman wrote:
--- MakeMaker.pm.orig Thu Oct 30 19:49:43 2003 +++ MakeMaker.pm Thu Oct 30 19:52:12 2003 @@ -381,7 +381,9 @@ foreach my $prereq (sort keys %{$self->{PREREQ_PM}}) { # 5.8.0 has a bug with require Foo::Bar alone in an eval, so an # extra statement is a workaround. - eval "require $prereq; 0"; + my $file = "$prereq.pm"; + $file =~ s{::}{/}g; + eval { require $file; 0 };
I've heard several times that 'eval { require $foo }' has problems with older perls, that's why you keep on seeing eval "require $foo".
I've never heard that, unless we're talking about MacPerl but that's unsupported by MakeMaker.
The reason you keep seeing
eval "require $foo";
is because to do it with an eval block its
my $file = "$foo.pm"; $file =~ s{::}{/}g; eval { require $foo };
Its unfortunate that require defaults to $_. :(
In other words, it's because $foo is not a bareword in this case.
But I did see many occurences of code where the module is hardcoded and is a bareword:
eval "require CGI";
when I was proposing to use the block, I'd always get the answer that it won't work with older perls.
Funny that while doing a sanity check I did:
% perl-5.8.2 -le 'my $mod = "threads"; require $mod' threads did not return a true value at -e line 1.
it actually read the directory 'threads' as a file. What would happen if the directory's contents happened to have a true value at the end? will require be sucessful? Shouldn't it test that the file it's going to read is actually a file?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
