VMS, configure.com and nonxs_ext

2009-09-07 Thread Nicholas Clark
This might be rather a big favour request.

Would it be possible to augment the configure.com code that finds extensions
to correctly partition nonxs_extensions from known_extensions?
(being the rather bonkers way that Configure partitions XS and non-XS
extensions)

To properly split out dual life modules into ext, I think it's going to be
necessary to add a Makefile.SH/Makefile/makefile.mk/descrip_mms.template
rule to have mkppport run after the nonxs_ext are built, but in turn, it needs
to run before dynamic_ext are built, hence the need for a split.

I'm not sure how easy this is, because right now Configure does it this way:

$ls -1 $xxx  $$.tmp;
if   $contains \.xs$ $$.tmp  /dev/null 21; then
known_extensions=$known_extensions $this_ext;
elif $contains \.c$  $$.tmp  /dev/null 21; then
known_extensions=$known_extensions $this_ext;
elif $test $this_ext = IO/Compress; then
known_extensions=$known_extensions $this_ext;
elif $test -d $xxx; then
nonxs_extensions=$nonxs_extensions $this_ext;
fi;
$rm -f $$.tmp;

using file globbing in ext/, whereas configure.com does it by text processing
MANIFEST:

$ known_extensions = 
$ xxx = 
$ OPEN/READ CONFIG 'manifestfound'
$ext_loop:
$   READ/END_OF_FILE=end_ext/ERROR=end_ext CONFIG line
$   IF F$EXTRACT(0,4,line) .NES. ext/ .AND. -
   F$EXTRACT(0,8,line) .NES. vms/ext/ THEN goto ext_loop
$   line = F$EDIT(line,COMPRESS)
$   line = F$ELEMENT(0, ,line)
$   IF F$EXTRACT(0,4,line) .EQS. ext/
$   THEN
$ xxx = F$ELEMENT(1,/,line)
$ IF F$SEARCH([-.ext]''xxx'.DIR;1) .EQS.  THEN GOTO ext_loop
$   ENDIF
$   IF F$EXTRACT(0,8,line) .EQS. vms/ext/
$   THEN
$ xxx = F$ELEMENT(2,/,line)
$ IF F$SEARCH([-.vms.ext]''xxx'.DIR;1) .EQS.  THEN GOTO ext_loop
$ xxx = VMS/ + xxx
$   ENDIF
$   IF xxx .EQS. DynaLoader THEN goto ext_loop ! omit
$!
$! (extspec = xxx) =~ tr!-!/!
$ extspec = 
$ idx = 0
$ replace_dash_with_slash:
$   before = F$ELEMENT(idx, -, xxx)
$   IF before .EQS. - THEN goto end_replace_dash_with_slash
$   IF extspec .NES.  
$   THEN
$   extspec = extspec + /
$   ENDIF
$   extspec = extspec + before
$   idx = idx + 1
$   goto replace_dash_with_slash
$
$ end_replace_dash_with_slash:
$   
$ xxx = known_extensions
$ may_already_have_extension:
$   idx = F$LOCATE(extspec, xxx)
$   extlen = F$LENGTH(xxx) 
$   IF idx .EQ. extlen THEN goto found_new_extension
$!  But Flirble may just be part of Acme-Flirble
$   IF idx .GT. 0 .AND. F$EXTRACT(idx - 1, 1, xxx) .NES.  
$   THEN
$   xxx = F$EXTRACT(idx + F$LENGTH(extspec) + 1, extlen, xxx)
$   GOTO may_already_have_extension
$   ENDIF
$!  But Foo may just be part of Foo-Bar so check for equality.
$   xxx = F$EXTRACT(idx, extlen - idx, xxx)
$   IF F$ELEMENT(0,  , xxx) .EQS. extspec
$   THEN 
$   GOTO ext_loop
$   ELSE 
$   xxx = F$EXTRACT(F$LENGTH(extspec) + 1, extlen, xxx)
GOTO may_already_have_extension
$   ENDIF
$!
$ found_new_extension:
$   known_extensions = known_extensions +  ''extspec'
$   goto ext_loop
$end_ext:
$ close CONFIG
$ DELETE/SYMBOL xxx
$ DELETE/SYMBOL idx
$ DELETE/SYMBOL extspec
$ DELETE/SYMBOL extlen
$ known_extensions = F$EDIT(known_extensions,TRIM,COMPRESS)


If it were possible to make the above into a function, then partitioning
nonxs from XS would seem to be as simple as

Feed the function the equivalent of `grep \.xs MANIFEST` to find the XS
extensions

Feed the function MANIFEST to find all extensions

Iterate over the list of all extensions - everything that isn't an XS
extension, you put into nonxs_extensions

But I don't know if functions are possible. And I can't see an easy way to
fit any sort of does this contain the substring '.xs' logic cleanly into
the above code, without wholesale copy-paste of may_already_have_extension
into one that does lines containing '.xs', and one that does not.

(I'm not sure why the Configure shell code contains tests for .c too -
historical reasons?
Also, it looks like some code can go from the above, now that there are
no directories with XS code in vms/ext)

If VMS does partition into nonxs_extensions correctly, I think that this tweak
would be needed:

diff --git a/make_ext.pl b/make_ext.pl
index 507f047..cfc12c2 100644
--- a/make_ext.pl
+++ b/make_ext.pl
@@ -179,6 +179,7 @@ elsif ($is_VMS) {
 $perl = $^X;
 push @extspec, (split ' ', $Config{static_ext}) if $static;
 push @extspec, (split ' ', $Config{dynamic_ext}) if $dynamic;
+push @extspec, (split ' ', $Config{nonxs_ext}) if $dynamic;
 }

 foreach my $spec (@extspec)  {

Nicholas Clark


Re: VMS, configure.com and nonxs_ext

2009-09-07 Thread Nicholas Clark
On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote:
 This might be rather a big favour request.

This might be easier than I first thought

 Would it be possible to augment the configure.com code that finds extensions
 to correctly partition nonxs_extensions from known_extensions?
 (being the rather bonkers way that Configure partitions XS and non-XS
 extensions)
 
 To properly split out dual life modules into ext, I think it's going to be
 necessary to add a Makefile.SH/Makefile/makefile.mk/descrip_mms.template
 rule to have mkppport run after the nonxs_ext are built, but in turn, it needs
 to run before dynamic_ext are built, hence the need for a split.
 
 I'm not sure how easy this is, because right now Configure does it this way:

 using file globbing in ext/, whereas configure.com does it by text processing
 MANIFEST:

 If it were possible to make the above into a function, then partitioning
 nonxs from XS would seem to be as simple as
 
 Feed the function the equivalent of `grep \.xs MANIFEST` to find the XS
 extensions

I think that every XS extension has exactly one file named *.xs in it. Try
running

perl -nlwe 'print $1 if m!^(ext/[^\/]+/\S+\.xs\b)!' MANIFEST

exclude from the output ext/DynaLoader (which is already a special case in
configure.com) and lines matching 'fallback/constants.xs' and one has
the list of all XS extensions. I hope that this algorithm is easy to
encode in DCL.

 Feed the function MANIFEST to find all extensions
 
 Iterate over the list of all extensions - everything that isn't an XS
 extension, you put into nonxs_extensions

At which point the existing code in configure.com can be changed around

$ may_already_have_extension:

to exclude any new extensions that are already in the list of XS extension
generated above, and tweak it to replace

$   known_extensions = known_extensions +  ''extspec'

with

$   nonxs_extensions = nonxs_extensions +  ''extspec'

Nicholas Clark


Re: VMS, configure.com and nonxs_ext

2009-09-07 Thread Craig A. Berry


On Sep 7, 2009, at 4:46 PM, Nicholas Clark wrote:


On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote:

This might be rather a big favour request.


This might be easier than I first thought


It occurred to me we ought to revisit this after getting vms/ext into  
ext.  I don't think it will be huge, but it does involve grokking some  
DCL that has to work rather hard to do what it's doing.  I'll take a  
look.


Would it be possible to augment the configure.com code that finds  
extensions

to correctly partition nonxs_extensions from known_extensions?
(being the rather bonkers way that Configure partitions XS and non-XS
extensions)



There's also dynamic_ext, right?  Shouldn't dynamic_ext plus  
nonxs_extensions equal known_extensions?


I think that every XS extension has exactly one file named *.xs in  
it. Try

running

   perl -nlwe 'print $1 if m!^(ext/[^\/]+/\S+\.xs\b)!' MANIFEST

exclude from the output ext/DynaLoader (which is already a special  
case in

configure.com) and lines matching 'fallback/constants.xs' and one has
the list of all XS extensions. I hope that this algorithm is easy to
encode in DCL.



Well, I think what we would do is something like

$ if f$search([.ext.''xxx']*.xs) .nes. 
$ then
$dynamic_ext = dynamic_ext +  ''xxx'
$ else
$nonxs_extensions = nonxs_extentions +  ''xxx'
$ endif

If xxx is Foo-Bar, that checks the filesystem for the presence of  
ext/Foo-Bar/*.xs.  This would have to be done before xxx has gone  
through the replace_dash_with_slash logic, or xxx could possibly be a  
saved dash-containing version that we drag around for this purpose.




Craig A. Berry
mailto:craigbe...@mac.com

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser