On 4/19/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
demerphq wrote:
> On 4/10/07, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
>> On 10/04/07, Jos I. Boumans <[EMAIL PROTECTED]> wrote:
>> > > The first files come from output_handle(), as far as I can tell;
>> isn't
>> > > there a way to delete them on close or at exit ?
>> >
>> > There is, cpanplus' Makefile.PL has a 'make clean' target that cleans
>> > all
>> > these up... but I'm not sure if/how we can call this from the test
>> > suite,
>> > or as part of perl's 'make clean'...
>> >
>> > > The dummy-cpanplus/* ones should maybe be cleared by a 99_cleanup.t
>> > > test ?
>> >
>> > They're all cleared by 'make clean' :)
>>
>> I can add them to bleadperl's make clean, but the problem is the
>> filename portability. Do we have .[0-9][0-9]_CPANPLUS files on all
>> platforms ? I'd rather have the information about the form of those
>> files in only one place. (The problem with removing the directory
>> dummy-cpanplus is less bothersome)
>>
>
> Attached patch is required to get CPANPLUS to do the right thing when
> being built as part of the core. The problem appears to be related to
> the code in ExtUtils::MakeMaker that does autodetection of the perl
> location when building on an uninstalled perl. It only checks up to 5
> directories above the current one, however Jos'es latests tests do
> stuff at 7 levels deep. Which means it doesnt realize its running on
> an uninstalled perl.
This is unlikely to work on most VMS filesystems which only allow 8 levels of
total depth. 1 for the perl source directory, assuming its been made into its
own root, 3 for lib/CPANPLUS/t then 7 more for the tests and you're at 11.
Actually 7 levels deep is from the test directory to the perl directory itself.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
