On Wed, 1 Nov 2000, Charles Lane wrote:
> Here's a revision of my previous patch that:
>
> (a) adds a check in configure.com to see if vms/perly_vms.c is up to
> date (i.e., if vms/vms_yfix.pl has been run)
>
> (b) modifies vms/gen_shrfls.pl to consult config.sh for whether GCC is used.
>
> The only changes are in (a), where I've followed Peter's suggestions and
> also rewritten the error message. With any luck, no one will ever see
> the error message, although I'm not quite that optimistic :)
>
> diff -uBb configure.com-orig configure.com
> --- configure.com-orig Tue Oct 31 17:31:07 2000
> +++ configure.com Tue Oct 31 17:47:43 2000
> @@ -677,6 +677,61 @@
> $ ENDIF
> $ DELETE/NOLOG/NOCONFIRM []ver.out;
> $ ENDIF
> +$!: check for perly/perly_c.vms generation
> +$ open/read CONFIG [-]perly.c
> +$ read CONFIG line
> +$ close CONFIG
> +$ match = "/* postprocessed by vms_yfix.pl"
> +$ if f$extract(0,f$length(match),line) .nes. match
> +$ then
> +$ torig = f$cvtime(f$file_attributes("[-]perly.c","CDT"))
> +$ tvms = f$cvtime(f$file_attributes("[-.vms]perly_c.vms","CDT"))
> +$ if (torig .ges. tvms)
> +$ then
> +$ type sys$input:
> +$ deck
> +
> +Uh oh, looks like vms/perly_c.vms wasn't updated. That sometimes
> +happens with new Perl releases, and should be considered a bug in the
> +release, albeit a fixable one.
> +
> +The suggested procedure at this point is to:
> + 1) Exit from this procedure
> + 2) Complain to the Perl Maintainers :)
> + 3) If you already have a working copy of Perl:
> + 3a) set default to the directory where this CONFIGURE.COM lives
> + 3b) do:
> + $ PERL VMS/VMS_YFIX.PL
> + 3c) do the @CONFIGURE again, there should be no more complaints
> + 3d) use MMS/K to build Perl.
> +
> + If you don't have a working copy of Perl, make sure you don't skip
> + step 2. Compiling Perl with an out-of-synch vms/perly_vms.c will
> + likely result in some obscure compile/link errors, so proceed at
> + your own risk.
> +
> + If this is a development version of Perl, it's quite likely that the
> + release just prior (or after) will not have this problem.
> +
> +$ EOD
> +$ dflt="n"
> +$ rp="Do you really want to continue? [''dflt'] "
> +$ IF (fastread) THEN fastread := FALSE
> +$ GOSUB myread
OK Charles this is not quite right. If I run a default build I obtain:
$ @configure "-Dusedevel" "-des"
First let's make sure your kit is complete. Checking...
Looks good...
Do you really want to continue? [n]
The portion that was confusing was that:
0) the message about perly_c.vms being out of date was not displayed
1) I mistook the "Do you really want to continue? [n]" prompt
for the one for usedevel.
2) fastread is never restored after this and I expressly wanted it to
be (although it looks like you've merely done the same thing as
the similar usedevel code...)
3) The test appears less than robust since I have:
$ dir [.vms]perly_c.vms/date=all
Directory DKB100:[PERL.VMS]
PERLY_C.VMS;1 199 1-NOV-2000 15:21:06.46 1-NOV-2000
15:21:06.62
<None specified> <No backup recorded> <None specified> <None
specified>
Total of 1 file, 199 blocks.
$ dir perly.c/date=all
Directory DKB100:[PERL]
PERLY.C;1 199 1-NOV-2000 15:21:33.86 1-NOV-2000
15:21:34.02
<None specified> <No backup recorded> <None specified> <None
specified>
Total of 1 file, 199 blocks.
I think this is due to looking via the symbol match for "postprocessed"
rather than "Postprocessed". But actually on closer inpsection it appears
to be problematic for this reason. The first line of my copy of perly.c
looks like:
#ifndef lint
and the first line of [.vms]perly_c.vms looks like:
/* Postprocessed by vms_yfix.pl 1.11 to add VMS declarations of globals */
At least the following patch to configure.com needs to go over your
proposed patch I think (but we may need something else too):
--- configure.com.orig Wed Nov 1 15:34:20 2000
+++ configure.com Wed Nov 1 15:41:06 2000
@@ -681,14 +681,14 @@
$ open/read CONFIG [-]perly.c
$ read CONFIG line
$ close CONFIG
-$ match = "/* postprocessed by vms_yfix.pl"
+$ match = "/* Postprocessed by vms_yfix.pl"
$ if f$extract(0,f$length(match),line) .nes. match
$ then
$ torig = f$cvtime(f$file_attributes("[-]perly.c","CDT"))
$ tvms = f$cvtime(f$file_attributes("[-.vms]perly_c.vms","CDT"))
$ if (torig .ges. tvms)
$ then
-$ type sys$input:
+$ cat4 sys$input:
$ deck
Uh oh, looks like vms/perly_c.vms wasn't updated. That sometimes
@@ -716,9 +716,12 @@
$ EOD
$ dflt="n"
$ rp="Do you really want to continue? [''dflt'] "
+$ tmp_fastread = fastread
$ IF (fastread) THEN fastread := FALSE
$ GOSUB myread
$ IF ans .EQS. "" THEN ans = dflt
+$ fastread = tmp_fastread
+$ delete/symbol tmp_fastread
$ IF ans
$ THEN
$ echo4 "Okay, continuing."
End of patch.
But that still does not solve the problem that the tar utility on unix
will screw up the CDT's of the perly.c file w.r.t. the vms/perl_c.vms
file I'm afraid.
Peter Prymmer
