Daniel writes:
>On Tue, 24 Feb 2004, Tor Arntsen wrote:
>
>> Something like the below should catch things like e.g. getdate.y:981: error:
>> too many arguments to function `Curl_gd_parse' (from
>> <http://curl.haxx.se/auto/log.cgi?id=20040224073821-32607>)
>
>Thanks! I made the fix slightly different, but the general idea is the same.
>
>Now, can you see how the generated getdate.c file looks like and see why this
>causes an error? This works on so many places it seems odd that this
>particular platform would create a bad C file from that .y file...

It *may* be because the bison version on that irix box is the one that came
with the operating system (1.25), not the freeware version (1.28) which I'm
using on the other (6.5.8) irix box.

Note that this didn't fail in the past. But I noticed in the log files that
it was referring to some directory that doesn't exist on the irix box, and in
fact getdate.c turned out to have been generated by a different bison, on my
aix box!

getdate.c gets created in the CVS curl directory only once: the first time
you run the autobuild. When I populated my autobuild boxes with CVS checkouts
of the curl directory I in fact copied from the first aix box to all the
others, instead of checking out from scratch on each of them. As the autobuild
doesn't re-build getdate.c they were all running with a getdate.c created by
the bison version on the original aix box instead of whatever version of
bison (or yacc) actually/currently installed on the autobuild box.

When I noticed that, I put a 'touch curl/lib/getdate.y' into the cronjob on
each autobuild box, so since a couple of days ago all my autobuilds are
re-creating getdate.c from getdate.y, with the local bison (or yacc I guess,
if there's no bison). That's when that strange error started to show up on
the irix box w/bison 1.25. I'll try installing a newer version of bison
and we'll see if it goes away (btw. I guess it could be useful to add a file
describing tools/versions needed to build curl).

I would suggest that autobuilds done from CVS really should re-create
getdate.c every time, otherwise you could for example install a new version
of bison that would fail to work with curl and you wouldn't notice because
you would still have the file generated with the old version. The below patch
would force re-building getdate.c from getdate.y for each new autobuild.

If there are arguments against doing this, then I suggest that a hint could
be added to the autobuild description webpage, mentioning the possibility of
adding a 'touch' command to autobuild cronjobs in order to properly test all
aspects of building curl.

-Tor

---
Index: testcurl.sh
===================================================================
RCS file: /repository/curl/testcurl.sh,v
retrieving revision 1.35
diff -u -r1.35 testcurl.sh
--- testcurl.sh	25 Feb 2004 09:03:09 -0000	1.35
+++ testcurl.sh	25 Feb 2004 12:04:27 -0000
@@ -145,6 +145,8 @@
 if [ -d "$CURLDIR" ]; then
   if [ $CVS -eq 1 -a -d $CURLDIR/CVS ]; then
     log "curl is verified to be a fine source dir"
+    # Force re-build of getdate.c from getdate.y:
+    touch $CURLDIR/lib/getdate.y   
   elif [ $CVS -eq 0 -a -f $CURLDIR/testcurl.sh ]; then
     log "curl is verified to be a fine daily source dir"
   else