Re: Problems with getdate.y, compiling on HP-UX 11i

[Mark D. Baushke]

Hi Daniel,

First, it looks like HP/UX 11i has a buggy version of make.
The timestamps of getdate.y and getdate.c should be the same
in the cvs-1.11.16.tar.gz

-rw-r--r-- 500/500       44418 2004-02-03 06:37:49 cvs-1.11.16/lib/getdate.c
-rw-r--r-- 500/500       25566 2004-02-03 06:37:49 cvs-1.11.16/lib/getdate.y

and a conforming version of make should only rebuild the getdate.c file
if getdate.y is NEWER, not if they happen to have the same time. As a
workaround, I suspect that 'touch cvs-1.11.16/lib/getdate.c' is correct,
then make will not try to build getdate.c for you.

Second, the version of bison that has been tested with getdate.y to
generate getdate.c is bison 1.35. Newer versions are not necessarily
supported.

Third, when I run either bison 1.35 or bison 1.875 on the lib/getdate.y
file, I get it to print a zero return code:

      % sh
      $ bison -y ./getdate.y
      conflicts: 10 shift/reduce
      $ echo $?
      0
      $

(I get this result on a FreeBSD 4.2-RELEASE system using either bison
1.35 or bison 1.875.)

I presume you must be getting a non-zero return code or your make would
not be failing where it is failing. Without further information I don't
know if this is a bug in bison or in HP/UX make.

Fifth, the reason there is a lib/getdate.c is to avoid the problems of
difference between HP/UX and Solaris implementations of that library
function. This is a replacment function from the GNULIB project.

        Good luck,
        -- Mark