|
From: | Daniel J Sebald |
Subject: | Bison/flex version upgrade doesn't reconstruct oct-parse.cc |
Date: | Tue, 09 Sep 2014 00:06:13 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
parse-tree/oct-parse.cc: In function 'int yypull_parse(yypstate*, octave_base_parser&)': parse-tree/oct-parse.cc:3977:14: error: 'yylex' was not declared in this scope
then updated Bison and flex to their most recent versions and eventually fixed the problem.
The one snag I ran into was the fact that the file oct-parse.cc is not updated or cleared by any of the common make processes going as far back as 'bootstrap'.
That is, I upgraded Bison, re-ran 'configure' and found that the generated file oct-parse.cc still indicated Bison version 2.4.3 in its header and--from the file date--was generated an hour prior to running 'configure'. Furthermore, 'make clean' doesn't remove the file. (Although, I should point out that my build directory is separate from the source tree.) Therefore, updating Bison to 3.0.2 had no effect until I rebuilt from scratch with an empty configure tree.
Forcing that parser regeneration will probably cause recompilation of the file oct-parse.cc and some other files every time "make" is run. Would it be possible to have a little script that searches oct-parse.cc for the Bison version and if it doesn't produce the same result as the working version of Bison, then update the file? Or is there a problem with that if someone builds from source files of the released version?
Should we at least remove the family of oct-parse.cc files with 'make clean'?
lex.cc oct-parse.cc oct-parse.output pt-binop.df lex.df oct-parse.df oct-parse.yy pt-eval.df oct-gperf.h oct-parse.h pt-arg-list.df pt-mat.df Dan
[Prev in Thread] | Current Thread | [Next in Thread] |