Jarkko Hietaniemi wrote:
>> Sorry about that... could the extension finding be made somehow dynamic?
>
> Just to clarify the obvious: I was under no misconception that just
> adding the new extensions to the list would make the new extensions
> magically build in VMS. It's just my not-so-subtle way of throwing
> the ball to you (and then quickly run away, myself), so to speak.
I ought to have been clearer myself: the extensions list does not
break in 9718 but if you add to it the various ext/ensions missing
from the VMS build then it breaks and my patch addresses both of
those issues.
Indeed the extension finding _should_ be done dynamically, and doing so
has been a longer term goal of the work on configure.com. The patch that
I provided earlier today is a first step toward that goal since it allows
for a larger list of extensions than is currently possible on VMS (prior
to the patch the limit was around 250 characters). A subsequent patch
should allow the extensions list to exceed about 1000 characters.
After that the task of dynamically generating the list could be
carried out but I'll mention some of the reasons why it hasn't
been done yet (apart from severe tuit shortages). The current
method used on more POSIXly oriented systems (this excerpted from
Configure in perl@9698 since it was handy at the time I wrote this)
looks a bit like:
: Function to recursively find available extensions, ignoring DynaLoader
: NOTE: recursion limit of 10 to prevent runaway in case of symlink madness
find_extensions='
for xxx in *; do
case "$xxx" in
DynaLoader|dynaload) ;;
*)
if $test -f $xxx/$xxx.xs; then
known_extensions="$known_extensions $1$xxx";
elif $test -f $xxx/Makefile.PL; then
nonxs_extensions="$nonxs_extensions $1$xxx";
else
if $test -d $xxx -a $# -lt 10; then
set $1$xxx/ $*;
cd $xxx;
eval $find_extensions;
cd ..;
shift;
fi;
fi
Note that this generates a case sensitive list with Unix style '/' path
separators: e.g. 'Data/Dumper Devel/DProf Devel/Peek Filter/Util/Call'
etc. Unfortunately, we do not have file system name case preservation on
VMS available from DCL (we do not even have automatic unix path
translations from DCL like we do from C and Perl). However, the case
preserved names are available in two spots: the C<package> declaration(s)
in the $xxx.pm file such as the ones in [.DATA.DUMPER]DUMPER.PM;1 (er, I
mean Data/Dumper/Dumper.pm ):
$ grep package Dumper.pm
package Data::Dumper;
# expects same args as new() if called via package name.
different package. The client is responsible for making sure the specified
different package) and then return it. The client is responsible for making
package Foo;
package Fuz; # a weird REF-REF-SCALAR object
package main;
package Foo;
package Foo::ZZZ;
package Foo;
So just grepping for package .* may prove dicy and may impose package
declaration format rules that might be just as meddle some as the current
chore of adding names to configure.com is now (it might still be
possible(?)).
The alternative is to look into the MANIFEST file for the case preserved
name of ext/ Makefile.PL's and $xxx/$xxx.xs files. configure.com
currently does parse the MANIFEST file (and it even converts
ext/Data/Dumper/Makefile.PL to [.ext.Data.Dumper]Makefile.PL not that we'd
necessarily need it) hence it may be possible to build the extensions and
known_extensions lists up from parsing the MANIFEST.;1 file.
I mention all of this since I see that the only consideration for case
non-preservation in Configure seems to be some equivalence between
e.g. Data/Dumper and data/dumper, but there may be more strange file
systems and ':' patch separators to consider (maybe not though).
Peter Prymmer
