Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK
Derek One of the things it does is verify that the requested executable Derek exists and that it is a GNU application. This is what caught us - the Derek script was assuming that any GNU program is good and therefore that Derek its failure meant a real failure. I added a new bison wrapper based Derek on missing to handle the version check. Let me know if it doesn't Derek work for you. Should I let you know if it does? Because it does. Thanks. Alex -- https://savannah.gnu.org/projects/libcvs-specAccess CVS through a library. PGP: ID: 0x23DC453B FPR: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B convince your customer that pserver access to a CVS server is, if not *actually* the work of the devil, then pretty similar -- Derek Price ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK
Alexander Taler wrote: $ make make all-recursive Making all in lib cp ./alloca_.h alloca.h-t mv alloca.h-t alloca.h /bin/sh ../build-aux/ylwrap getdate.y y.tab.c getdate.c y.tab.h getdate.h y.output getdate.output -- /bin/sh /home/dissent/prj/libcvs/var/ccvs-1.12/build-aux/missing --run bison -y /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:202: unrecognized: %parse-param /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:202:Skipping to next % /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:203: unrecognized: %lex-param /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:203:Skipping to next % *** Error code 1 There are a few issues here: 1. getdate.y from GNULIB requires at least Bison 1.875. 2. getdate.y shouldn't be recompiled unless it has changed, but sometimes the timestamps can get munged when checking out of CVS. 3. When either of the above two problems are not avoided, the build-aux/missing script is supposed to just update the timestamps, print a warning message, and exit with a success code. This may not happen if your lib/getdate.c file is actually missing, for instance if you ran a `make maintainerclean'. If your `missing' script is failing for any reason other than a bad bison AND a missing lib/getdate.c, then I would like to get to the bottom of it. Otherwise, your solution should be to update to a more recent Bison (which we assume for anyone willing to run `make maintainerclean'), or pull the current lib/getdate.c from CVS and avoid the rebuild. I have documented the Bison 1.875 requirement in HACKING. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK
Alexander Taler wrote: case $1 in --run) # Try to run requested program, and just exit if it succeeds. run= shift $@ exit 0 Where do you suppose that check should be? Actually, `missing' only `exit 0's when the program exited with a success code. Otherwise it will fall through and perform various actions depending on the argument to --run. One of the things it does is verify that the requested executable exists and that it is a GNU application. This is what caught us - the script was assuming that any GNU program is good and therefore that its failure meant a real failure. I added a new bison wrapper based on missing to handle the version check. Let me know if it doesn't work for you. This problem should go away when we start using Automake 1.10 since it won't allow Yacc targets to be built without the --enable-maintainer-mode argument to configure. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
