At 6:01 PM -0700 7/31/03, Mark Berryman wrote:
>
>First, the command line:
>MCR [---]miniperl.exe  [-.bin]enc2xs -"Q" -"O" -o BYTE_T.C -f byte_t.fnm
>
>Second, DECC$ARGV_PARSE_STYLE is defined.  This logical removes the need
>to quote mixed-case or uppercase arguments to C programs on VMS.

If disabling this feature (thus returning to the default behavior)
gets things to build properly, that may well be the recommended
workaround.

>Third, the following check in [.EXT.ENCODE.BIN]ENC2XS.:
>if ($cname =~ /\.(c|xs)$/)
>
>So, with the logical name defined, the filename BYTE_T.C was not
>converted to lowercase but the code only accepted the file as a C file
>if the extension was lowercase.  Bad code.  Bad.  Bad.

It's not clear to me where the filename got upcased.  I'm not at all
sure it's related, but at the moment Perl does not support
DECC$EFS_CASE_PRESERVE because MakeMaker is not prepared to handle
it.  That means we follow the old practice of downcasing all
filenames, so it's a bit surprising we get BYTE_T.C.  It may well be
there's something in MakeMaker that turns Foo.c into FOO.C, or
perhaps it's in the very complicated code-generating scripts that are
part of the Encode build process.

Once upon a time, testing was a matter of iterating over a matrix of
dimensions i, j, k, where i is VMS version, j is Perl configuration,
and k is C compiler version.  Now it's an i, j, k, l matrix, where l
is a dimension representing feature enabling logical names for the
CRTL.  (Actually, the foregoing leaves out dimensions representing
network stack and hardware architecture).

<Very sensible-looking code changes snipped.>

>Any chance of any of these changes being made official?

The chances improve when you present a GNU unified diff to
[EMAIL PROTECTED], preferably cc'ing vmsperl.  GNU diffutils is
available from the v5.0 VMS Freeware CD and elsewhere.  Second best
are changes submitted here only in DIFFERENCES/SLP format.  Third
best are verbal descriptions of the changes.  These latter two
options depend on my formulating them into unified diffs, testing
them, and submitting them to p5p and/or the pumpking directly.  I'm
happy to be the intermediary, but I'm not always awake, quick, or
efficient at being the intermediary.
-- 
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

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

Reply via email to