On Thursday, April 18, 2002, at 03:34 PM, Andreas J. Koenig wrote:
>
> manifind always was doing just a find, no analysing.
That changed with a patch I submitted a couple months ago. Most of your
patch just undoes my patch. ;-)
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.
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? 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::*.
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?
-Ken
