On Thu, 2 Nov 2000, Charles Lane wrote:
> > 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...)
>
> My fault, I just copied DCL from elsewhere in CONFIGURE.COM.
Yes the usedevel code is deceiving in that it gets skipped if you have the
symbol usedevel or if you invoke configure.com with "-Dusedevel" (therby
setting the usedevel symbol to "define". But if someone did neither then
it was deemed likely that configure ought to be careful and ask each
question explicitly. The use of the temporary variable for the perly
question ought to suffice.
> > > 3) The test appears less than robust since I have:
> >
> (reformatting Peter's directory listings for greater clarity:)
> CDT RDT
> [.vms]perly_c.vms 1-NOV-2000 15:21:06.46 1-NOV-2000 15:21:06.62
> perly.c 1-NOV-2000 15:21:33.86 1-NOV-2000 15:21:34.02
>
> > 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 */
>
> The "post..." vs. "Post.." was a typo on my part, thanks for catching it.
>
> You're right that the times on your files are problematic; when trying out
> the code on my system with a recent bleadperl I got:
>
> CDT RDT
> PERLY.C 25-OCT-2000 13:26:53.00 31-OCT-2000 15:16:37.64
> vms/PERLY_C.VMS 25-OCT-2000 13:27:14.00 31-OCT-2000 15:18:21.03
>
> Note the large difference between CDT and RDT. The RDT reflects the
> time when the tar file was unpacked, while CDT is (apparantly) a time
> obtained from the contents of the tar file. Sounds like we're using
> different tar programs.
>
> I guess the patch relies too much on tar or unzip preserving file
> times.
>
> Another possible approach would be to encode some sort of "which
> perly.c this came from" into the header for vms/perly_c.vms. There's
> no version # in perly.c, so something like a file checksum is indicated.
>
> DCL CHECKSUM would be fine, except we need to generate it on Unix systems
> too...Perl+MD5 is also fine, except that we won't have a working Perl when
> we need to test perly.c against vms/perly_c.vms.
Is checksum an optional thing? I've found an Alpha running VMS V7.1 that
has no help module for `HELP CHECKSUM` and trying to invoke it proved
rather unhelpful:
$ checksum login.com
$
(no output, no number nothing). I suspect that even on
> Are there other possibilities that I'm missing?
What about using the comparison of a delta to an epsilon such as is used
for floating point number comparisons instead of '=='? That is, something
along these lines allows for up to an hour delta between perly.c and
[.vms]perl_c.vms and still lets the former be "newer" than the latter,
allowing a pumpking to `touch perly.c` or check it into Perforce or do
whatever it is that they do to mess with the CDT (this goes on top of your
patch and my patch from yesterday):
--- configure.com_patched Thu Nov 2 10:36:11 2000
+++ configure.com Thu Nov 2 10:35:05 2000
@@ -685,8 +685,10 @@
$ if f$extract(0,f$length(match),line) .nes. match
$ then
$ torig = f$cvtime(f$file_attributes("[-]perly.c","CDT"))
+$ torig = f$extract(0,f$locate(":",torig),torig)
$ tvms = f$cvtime(f$file_attributes("[-.vms]perly_c.vms","CDT"))
-$ if (torig .ges. tvms)
+$ tvms = f$extract(0,f$locate(":",tvms),tvms)
+$ if (torig .gts. tvms)
$ then
$ type sys$input:
$ deck
End of patch to patch to patch.
For my patched tarball I obtained these strings:
$ sho sym torig
TORIG = "2000-11-02 10"
$ sho sym tvms
TVMS = "2000-11-02 10"
and note the change to .gts. from .ges.
Peter Prymmer
