[Module-build-general] Re: MB MacOS fixes

[Ken W. <ke...@ma...>]

On Thursday, November 28, 2002, at 01:14  PM, Michael G Schwern wrote:

> On Thu, Nov 28, 2002 at 12:39:16PM +1100, Ken Williams wrote:
>>> - 'use blib' normally looks for blib/lib and blib/arch but on
>>> MacPerl, for
>>>  some reason, it looks for blib/lib and blib/MacPerl.  Probably some
>>>  MakeMaker wackiness.  As M::B follows a more sane naming scheme the
>>>  exception in blib.pm screws things up.  So we just use the
>>> much simpler
>>>  and much quieter "use lib blib/lib blib/arch"
>>
>> The problem isn't that it's looking for blib/MacPerl (at least,
>> not on my box, 5.6.1r1), it's that it's blindly applying Unix
>> naming conventions.  When I fixed those, 'use blib;' worked fine.
>
> I'm using the 5.8 MacPerl alpha.  5.8.0 changed blib to do the Mac 
> specific
> arch directory.

ok.


>> But you're right, we don't really need it to search up & down
>> the file tree, we can just add these libs directly (though with
>> File::Spec - I suspect it was finding your previously installed
>> copy?).
>
> I think @INC will accept Unix style filenames.  Or maybe this was only 
> fixed
> in 5.8.

It doesn't work in 5.6.1, unfortunately.  I'm not sure whether it was 
just the lib.pm changes or changes in how @INC is used by require() and 
use() and friends, though.

In any case, a slash in a filename under MacOS is ambiguous, since 
files & directories can contain actual slash characters.  There's a 
comment in pp_ctl.c about this.  So it looks like it's preferred to have 
locally native paths in @INC.  Correct me if I'm wrong on this.

>
> My previously installed copy of what?  Module::Build?  Hadn't installed 
> it.

Hm, must have been the 5.6 vs. 5.8 difference then.

Unfortunately, the 'use lib qw(lib);' thingy generates other problems on 
MacPerl 5.6.1 in conjunction with Mac::MoreFiles (which is used by 
File::Copy, which is used by Module::Build), which I'll detail in a 
separate message to ma...@pe....


>>> build, help, distcheck, distclean, clean and realclean were
>>> confirmed to
>>> work.  test should work with ToolServer, Test::Harness is the problem.
>>> fakeinstall and install work with a repaired ExtUtils::Install.
>
> I was thinking about this, and I think I have a solution to the
> ExtUtils::Install problem.  It goes something like this:
>
> use ExtUtils::Install;
>
> {
>     no warnings 'redefine';
>     sub ExtUtils::Install::find {
>         my($code, @dirs) = @_;
>
>         @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;
>
>         return File::Find::find($code, @dirs);
>     }
> }
>
> ie. MacOS.pm can load ExtUtils::Install and replace its directly import
> File::Find::find() with a wrapper find() which fixes the hard coded '.'
> problem. That way MacPerl/Module::Build users won't have to upgrade
> MakeMaker.

Looks good.  I'm adding it like this, in Platform/MacOS.pm:


--------------------------------------------------
# ExtUtils::Install has a hard-coded '.' directory in versions less
# than 1.30.  We use a sneaky trick to turn that into ':'.
#
# Note that we do it here in a cross-platform way, so this code could
# actually go in Module::Build::Base.  But we put it here to be less
# intrusive for other platforms.

unless ( eval {ExtUtils::Install->VERSION('1.30')} ) {
   no warnings 'redefine';
   *ExtUtils::Install::find = sub {
     my ($code, @dirs) = @_;

     @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;

     return File::Find::find($code, @dirs);
   }
}
--------------------------------------------------

  -Ken