On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:
> Peter Prymmer <[EMAIL PROTECTED]> writes:
> > The time has apparently come to get rid of the attempt to pass
> > a list of extensions to build to the make_ext.com script.
> > The enclosed patch introduces a new extensions.lis file to the
> > main build directory and re-writes make_ext.com to use it
> > in place of p1. I've also included a VMS portability patch for
> > ext/Cwd/Cwd/xs.
> >
> > Are there any questions or comments on this approach? I thought I'd
> > let vmsperl mull it over before I send into p5p + pumpkings.
>
> Peter,
> it's good that you're looking at this stuff!
>
> I presume that you don't want to have make_ext.com get the
> list of extensions from config.sh because of DCL symbol length
> limitations....otherwise it would be better to use config.sh
> and not have config information duplicated in extensions.lis.
>
> But the list of extensions has to fit in a single DCL symbol (length
> <1024 IIRC) because that's what we use to store the list in
> configure.com before writing it to config.sh, and the same symbol is
> then used for writing to extensions.lis.
We have not yet hit the 1024 limitation that is practically speaking less
than 1024 since some bytes have to hold the variable name (extensions or
tmp in the case of configure.com). From HELP := we see:
Parameters
symbol-name
Specifies a string of 1 to 255 characters for the symbol name.
string
DCL uses a buffer that is 1024 bytes long to hold a string assignment
statement. Therefore, the length of the symbol name, the string,
and any symbol substitution within the string cannot exceed 1024
characters.
while we are not yet near the 1024 byte limit we have bumped into the 252
byte limit in passing a parameter from MMS to DCL as the $(extensions) p1
parameter passed to make_ext.com (sorry but I did not save the error
message from yesterday's test builds).
Another thing about the extensions and known_extensions symbols is that
that will not go through $write sys$output "''extensions'" at the current
size. I did manage to save those error messages:
Do you wish to attempt to use the malloc that comes with perl5? [n]
%DCL-W-TKNOVF, command element is too long - shorten
\[re B Cwd Data::Dumper Devel::DProf Devel::Peek Digest::MD5 Encode Errno
Fcntl
File::Glob Filter::Util::Call IO List::Util MIME::Base64 Opcode
PerlIO::Scalar
PerlIO::Via SDBM_File Storable Sys::Hostname Thread Time::HiRes
VMS::DCLsym VMS:
:Stdio XS::Type
Which "make" utility do you wish to use? [MMS]
> However, looking at [.vms]munchconfig.c and ConfigPM., it seems that we
> can split long config.sh symbols:
>
> blah="stuff stuff stuff stuff
> morestuff morestuff morestuff"
>
> Although I rather doubt that munchconfig's capabilities have been tested
> WRT split config.sh lines (and it probably needs to use malloc'd strings
> rather than fixed buffers to avoid length limits), this does seem to
> provide a way to keep individual lines of config.sh within bounds, yet
> store a long list of extensions.
I will be worried about long lists of extensions when we get closer to
the 1024 limit I suppose. I had thought (quite a while back) about having
configure.com do something analogous to what the Bourne shell script does
- but - it makes extensive use of case preservation of the Unix file
system that we cannot rely on.
> My suggestion is to have the take the list of extensions (stored in
> multiple DCL symbols) to generate multi-line config.sh entries. Then
> have make_ext.com read config.sh for the list of extensions to build.
Thanks for the suggestion. Currenty config.sh is Bourne shell syntax not
DCL so we cannot issue:
@config.sh
and have the extensions symbol automatically assigned in our local DCL
scope. I reached for the extensions.lis file for a couple of reasons:
1) it was an analog of a linker options .opt file 2) it seemed that it
would be really easy to parse 3) it seemed that it would be really easy to
modify by the end user. As it stands I cannot now use EDT to edit my
config.sh since it exceeds EDT's 255 character per line limit - hence I
have to use TPU or VIM.
Apart from your suggestion of having make_ext.com grab info from config.sh
(which we might do with a SEARCH rather than a parse?) we might also
consider adding "''extensions'" to make_ext.com directly (Whilst hacking
yesterday I had wished that DCL had an __END__ token and could read from
<DATA>).
The problem with splitting up the extensions variable in config.sh comes
from the regression tests that tend to do things like:
BEGIN {
use Config;
if $Config{extensions} !~ /\bFoo\/Bar\b/
print "1..0 # Module Foo::Bar not built here.\n";
exit;
}
(which BTW is something that the current [.lib]u-*.t tests do not do
(sic)). But I suppose they could be rewritten to multiline matches
if we have to resort to that eventually.
On the other hand there must be several Unix shells with a command line
length limit (while 1024 is small there might still be some with 2048 or
so, vendor csh shells tend to be much worse in that regard though).
Thanks for the suggestion. Having the one single source of info for
extensions=' very long list ' in only config.sh is a good idea. I'll
see if I can cobble it up.
Peter Prymmer
