Closed felix-salfelder closed 7 years ago
I restarted one of the Travis instances. It stalled while fetching from CPAN. It builds fine on Linux with bison-2.5.
There is an issue on Windows with bison-2.4.1.
https://ci.appveyor.com/project/qucs/adms/build/1.0.12#L270
C:/projects/adms/cmake_build/admsXml/verilogaYacc.y:1299.49: warning: stray `$'
[ snip ]
C:/projects/adms/cmake_build/admsXml/verilogaYacc.y: In function 'verilogaparse':
C:/projects/adms/cmake_build/admsXml/verilogaYacc.y:1299:49: error: '$R_analogcode' undeclared (first use in this function)
gModule->_analog=adms_analog_new(YY($R_analogcode));
^
Perhaps the older bison does not support named references to tokens?
Perhaps the older bison does not support named references to tokens?
this is very likely. thank you for digging the logs. now, bison 2.4 is 7 years old, for comparison, bison 2.5 is 4 years old. would it be of any disadvantage to just build depend on 2.5?
i tend to be conservative about unneccessary dependencies. i did not intentionally use named references, only picked them from a manual by chance. but i would like to see them used more often, rather than banned.
(YMMV. sure i'll try to work around this, if 2.5 is not tolerable on some system...)
I guess it makes sense to move forward and use named referenced tokens. Just make sure we bump the configure/cmake to check for bison 2.5+.
The bison-2.4 is the one bundled with Git for Windows (pre-installed on the AppVeyor instance), I used that for convenience. I will try to fetch a newer version.
Can you do a rebase? I pushed the changes for the bison-2.5 to master. I tested locally, but I have bison-3+ on my Windows box.
Do you have a short XML example for test/documentation of this changes?
I am looking to test this PR. Do you have the .va file you used to test this?
Second (unrelated) question, What do you think. Should we keep using the mkgrammar.pl
?
theres a test in a49b8d902929a5774696316dfc0fc1667f13ec8b. it uses a dummy parameter. with this PR, the test should also work without the dummy parameter.
Should we keep using the mkgrammar.pl?
to me, it makes some sense to create a parser from the language description. it would be hard to do it the other way round ... this will start to make sense as soon as somebody wants to write a non-lex/yac parser :D
(no guarantees)
the parser for parameter lists in subdevice instanciation is wrong. unfortunately, the grammar defined by the standard is context sensitive, hence a few more commits.