Peter Prymmer <[EMAIL PROTECTED]> wrote:
> 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)
(patch elided)
> 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...)
My fault, I just copied DCL from elsewhere in CONFIGURE.COM.
> 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.
Are there other possibilities that I'm missing?
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
