At 10:28 AM 3/5/2001 +0000, Michael G Schwern wrote:
>On Sat, Mar 03, 2001 at 11:58:54PM -0600, Craig A. Berry wrote:
>> Been there, done that.  I think it could also grab modules from the
>> library path of your installed Perl in this situation.
>
>That's what was breaking the test in the first place (well, one of the
>things).  

Right.  I was describing why things appeared to work after Charles's patch 
but didn't really.

>In short, tests shouldn't break because we added a new module to the
>source.

Agreed.

>> Moving higher in the directory tree and/or keeping find.t's private
>> play space shallower seems preferable to changing the current
>> directory.
>
>How much shallower?  t/pod/sample_pods/Pod/Stuff.pm still too deep?

No, I think that should actually work.  There were two or three more levels 
than that in your original patch IIRC.

>I'd really, really, really like to keep the test data for a particular
>set of tests as close to the test itself as possible.  I'd also like
>to keep them as segregated as possible.
>
>So we've got effectively six levels to play with when the smoke
>clears?  Two of the eight eaten up by /src/perl-current, (pardon the
>Unixisms) or would it more typically be three leaving us five?

The device name doesn't count, so the way I usually build it'd be one taken 
up by perl-current, but in Chuck's example he was building under 
perl/perl-current (or equivalent).  

One measure of what's doable is what's already done, and the deepest thing I 
find in the manifest is this:

ext/IO/lib/IO/Socket/INET.pm

So, going five levels deeper than the main source directory seems to have 
precedent, meaning either of the following wouldn't be breaking new ground:

t/pod/sample_pods/Pod/Stuff.pm
t/pod/sample_pods/lib/Pod/Stuff.pm

One level deeper than that could work in principle but might require some 
people to relocate their usual build trees or define a rooted logical name.  
The latter process is described in README.vms (search for 'depth'), but 
ideally we would not require this workaround in situations that didn't require 
it before.


Reply via email to