Peter Prymmer <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Nov 2000, Charles Lane wrote:
>> > > 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
>> 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
You look in the symbol CHECKSUM$CHECKSUM. AFAIK, checksum has been
part of VMS since 'way 'way back. But the problem is that we'd have
to generate it on a Unix system...maybe if we could come up with a
Perl module that duplicates checksum's functionality, but IIRC checksum
is just using the old VAX "CRC" instruction (or emulated equivalent). But
I think we have a way out, see below.
CHECKSUM/IMAGE when applied to an EXE gives a nice section-by-section
checksum output, BTW
>> 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):
Putting an "epsilon" around the CDT doesn't help, because what we're
trying to sense is if the distribution didn't have vms_yfix run. If
the CDTs resulting from tar unpacking don't reflect the original
creation times, then they don't tell us one way or the other.
How about this: modify vms/vms_yfix.pl do the following:
copy perly.c -> vms/perly_c.orig
process perly.c -> vms/perly_c.vms
Then have configure.com:
compare CHECKSUM's of perly.c against vms/perl_c.vms
if the same, okay we're done
ELSE
compare CHECKSUM's of perly.c against vms/perly_c.orig
if the same, we need to copy vms/perly_c.vms -> perly.c etc.
ELSE
complain bitterly
So all that has to happen extra on the Unix side is a file copy,
and we can use CHECKSUM from DCL to see if vms/perly_c.vms has been
generated properly.
I'll see about working up a patch based on this; in the meanwhile, are
you happy with the gen_shrfls patch?
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
