Hello v, Your posting generated some internal private discussion on the bug-coreutils mailing list. You could read it through the web archive. But I don't believe anyone has responded to you yet. So let me summarize the problem and include you in the discussion. Please keep replies to the mailing list so that everyone can participate.
vy wrote: > I've been getting cvs updates of the coreutils file set to build with > a view to eventually adding documentation in info and manpage format. Very good. Updates to the documenation are appreciated. > I've not ever built coreutils successfully on my Mac os x 10.4.6 > computer. Previously I could get past the `configure' stage, at the > `make' stage the building process would stop on this instruction > `bison -y getdate.y', ie. > > roamantic:~/continuing/_study/coreutils/lib vy$ bison -y getdate.y > getdate.y:215: unrecognized: %parse_param > getdate.y:215: Skipping to next % > getdate.y:216: unrecognized: %lex_param > getdate.y:216: Skipping to next % Thanks for reducing this to the smallest problem case. I assume that the 'make' failed and this was what the failure reduced down to as a small example. This probably means that your version of bison is too old. I don't know the details of %parse_parm but I will assume that you need to update your version of bison. I do not see this issue when using bison 1.875d from Debian Sarge for example. What version are you trying to use here? bison --version When building programs from CVS you will need to ensure that you have good versions of all dependent tools. I don't know the complete list but certainly bison, autoconf, and automake at the least. > Now, I am having trouble with > > roamantic:~/continuing/_study/coreutils vy$ ./configure > --prefix=/Users/vy/local --exec-prefix=/Users/vy/local/ppc > ./configure: line 9: =======: command not found > ./configure: line 12: syntax error near unexpected token `>>' > ./configure: line 12: `>>>>>>> 1.277' > > I suppose the configure issue is transient, any ideas about the > make/bison issue? I have begun to read the bison infopages to get a > grip. Those look like CVS conflict markers placed in the file after a conflict when doing a CVS update. What typically happens is this. The upstream developer has checked in generated files. You are also generating those files. The generation will never be exactly the same if the versions of the tools are different and will rarely be exactly the same if generation dates are encoded in the file. On the first checkout from cvs all files will be the checked in copy. Then you will generate new derived files. The problem comes when you update from the master sources and cvs tries to merge the upstream changes with your generated changes. This almost always conflicts and cvs will place conflict markers in the file. Generally the way I handle this on my end as a downstream consumer of cvs checkouts is to remove everything and check out a fresh copy again from scratch. I rarely cvs update in coreutils due to the problems of dealing with generated files. (Other projects without committed generated files update fine however.) That is what I suggest. I suggest you create a clean cvs checkout, avoid cvs update, and build from there. Alternatively you can simply remove the generated files such as configure and rebuild them. Your build then would not have the cvs checkout conflict markers and should work fine. Assuming that your version of the build tools are sufficient to build the project of course. Bob _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
