>>>>> On Thu, 18 Apr 2002 17:50:53 +1000, Ken Williams <[EMAIL PROTECTED]> said:
> That changed with a patch I submitted a couple months ago. Most of
> your patch just undoes my patch. ;-)
Sigh.
> The reason it was patched is that if the working directory contains a
> subdirectory with lots of files in it (say, a corpus of 200,000 news
> articles), then operations like 'perl Makefile.PL' will take forever,
> even if the offending directory is listed in MANIFEST.SKIP and don't
> have any bearing on what's actually being accomplished.
The patch that broke the camel's neck was 15599 and when I read that,
I recognize what you describe as your patch. It broke the original
semantics of manifind which was documented:
manifind() returns a hash reference. The keys of the hash are the
files found below the current directory.
I'm using manifind in programs as a handy wrapper myself. They will
break with this change.
If you want a faster mkmanifest() that works without manifind due to
performance considerations, you should probably write a
fastmkmanifest() without touching manifind().
> On Thursday, April 18, 2002, at 03:01 AM, Andy Dougherty wrote:
>> One place where this shows up is in Parrot 0.0.5 :-(.
>> Try the following in your parrot source directory:
>>
>> perl -MExtUtils::Manifest=manicheck -e manicheck;
>>
>> With 5.005_03, it will exit cleanly. With 5.7.3 (@15929,
>> built this morning) you'll get
>>
>> No such file: examples/assembly/Makefile
>> No such file: languages/cola/Makefile
>> No such file: languages/regex/Makefile
>>
>> These files exist. If I remove the line
>>
>> /Makefile$
>>
>> from parrot's MANIFEST.SKIP, then it again runs cleanly.
> That line should be
> ^/Makefile$
> instead, right?
No.
> If that fixes the problem, then I'll support the
> notion that this was a bug in the MANIFEST.SKIP, not a bug in the
> 5.7.3 ExtUtils::*.
I don't think so, the bug is now in manifind().
> It seems to me that a function called 'manifind()' should be
> respecting the rules of building the MANIFEST, including
> MANIFEST.SKIP. If not, what differentiates 'manifind()' from
> 'File::Find::find()', and what point is there in having the former?
manifind, as it was originally written, was a thin wrapper around
File::Find, eliminating directories, eliminating leading "./" and
adjusting itself to Mac and VMS, nothing more.
--
andreas
