The patch below only affects VMS. It works around a problem where
File::Find can go haywire when a directory name collides with a logical
name. For example,
File::Find::find(sub {...}, 'foo');
will have two quite different behaviors depending on whether foo is defined
as a logical name. If it is defined and the logical points to a directory,
the search will use that directory rather than the relative path ./foo,
which is usually what is meant. This causes various breakages and can
potentially be dangerous when building extensions on VMS. For example, if
BASEXT is "Util" (as with List/Util) and a UTIL logical name points to my
local system's utility programs, the build of the extension fails because it
can't find any of the stuff under ./Util and -- worse yet -- my utility
programs end up in the clean and realclean targets in the makefile.
The patch below dodges the issue by wrapping directory syntax around the
directories that are passed to File::Find when building extensions, forcing
them to be considered as relative paths. A better fix would address this
within File::Find, but I have not been able to come up with something that
works (or at least doesn't break something else). I've just about concluded
that File::Find is not fixable, i.e. it's assumptions about what can be done
with the pieces of a filename are just too different to be completely portable.
--- lib/ExtUtils/MM_Unix.pm;-0 Sun Jun 16 09:27:03 2002
+++ lib/ExtUtils/MM_Unix.pm Mon Jul 8 11:48:57 2002
@@ -1349,8 +1349,15 @@
# (which includes PARENT_NAME). This is a subtle distinction but one
# that's important for nested modules.
- $self->{PMLIBDIRS} = ['lib', $self->{BASEEXT}]
+ if ($Is_VMS) {
+ # avoid logical name collisions by adding directory syntax
+ $self->{PMLIBDIRS} = ['./lib', './' . $self->{BASEEXT}]
unless $self->{PMLIBDIRS};
+ }
+ else {
+ $self->{PMLIBDIRS} = ['lib', $self->{BASEEXT}]
+ unless $self->{PMLIBDIRS};
+ }
#only existing directories that aren't in $dir are allowed
[end of patch]
