Dan Sugalski wrote: > There aren't that many symbols in configure.com, though it has grown since > the original. Subconfigure.com, on the other hand, has scads of them--one > for each variable in config.sh. That's way too many, but it seemed like a > good idea at the time. You'll notice that all the variables that hit > config.sh are in a perl_ format. I'd intended originally to have a loop > through all the symbols that matched perl_* and write them out rather than > write them all individually, but that didn't work out. Yes its true there aren't many symbols in configure.com and a few; such as ans, file_2find, and dflt; are recycled for various purposes so as to minimize the impact on the local symbol table size. I doubt that we can go head to head with the symbols (shell variables) in Configure's `cat <<EOF` -> config.sh on Unix. DCL's local symbol table size just does not scale the way the Bourne shell's do (admittedly at least it is adjustable). But even on OSes like DOS (running bash under djgpp or epoc (not sure which shell they use) they've got a typical DCL process beat. I'd like it if we could ensure that MicroVAXEn can at least configure the build for perl and not make a 8 GIGs of RAM TurboLaser (or HPC 320) a requirement just to configure the build. Then too there are config variables that will always be eq '' or 'undef' or 'define' on VMS and they ought not even incur the expense of any symbol d_foo or perl_d_foo. Hence there are at least three classes of conf variables: those that are completely ignorable on VMS and do not even need to be in our config.sh, those that take certain fixed values such as '' or 'undef', etc.; and finally those that require some algorithm and possible calles to lexicals and or test compiles to discern what VMS has and possible distinctions between versions of VMS and/or compilation environments. Note that user preferences such as the installation ''predix' fall into the latter class. Any automated way to do a unix kit update -> VMS configure.com ought to be able to handle those three classes. Admittedly the last category is tough to automate, but some stub code to be filled in by hand could at least be generated and flagged (e.g C<print " Hey Sarathy send email to [EMAIL PROTECTED] and ask them about how to link a try.c that probes the sysV IPC library on VMS\n";>). > >before doing your diff. Please note that I've not sent this to p5p, Jarkko, > >or Sarathy and they won't see any of it unless one of us does send it in. > > It's a bit big, but it looks OK. I'm holding off until RC2 only because > we're so close and Charles was in there too. It might wait until the > overhaul, though I'd rather see it in sooner than later. It does a few things that affect the @INC settting and the config_args config varaible. The size of the patch is large beacuse of the large number of s/(if variable)\Q.eqs."YES"\E/$1/ type of edits that have no impact on functionality. Peter Prymmer
