On 2020-10-13 06:15, Arily Essen via Firebird-devel wrote:
2. (drawing on long-term experience)
- I have seen some old threads (for instance "BTYACC" starting on Dec
4, 2004) where pros/cons of different types of parsers and parser
generators were discussed in the context of porting/migration to btyacc.
To any who were there: in hindsight, have your views on this subject
changed significantly? was the switch a complete net gain?
I think goals discussed that time were satisfied with switch to btyacc
completely.
3. (build dependency-related questions)
- Would adding an additional build dependency be a significant,
unconditional barrier to adoption in the official source?
- What criteria are most important in choosing to adopt new build
dependencies for the project? I wish to keep my options open as much
as possible here.
I imagine that a full python interpreter is not desirable as a build
dependency.
What about, for instance, a minimal C-embedded Lua interpreter?
A bespoke tool written in an existing C/C++ library? (I see that
Boost.Preprocessor is currently included in the source)
- How much would it matter if such a dependency required an additional
build step, like CLOOP and btyacc?
We have 2 different, independent build processes: for posix (mostly
linux tested) and windows. In the first case use of any mentioned tool
is not a problem on my mind. But in the second - even grep is a problem
:-( Probably the best choice is to have additional dependency like CLOOP
/ btyacc.
other related comments and advice are of course welcome
btyacc builds just a skeleton of grammar, some details are resolved
later. For example, good from btyacc POV statement "CREATE USER U1
FIRSTNAME 'UUU';" is wrong cause missing password clause, but that's
detected later - not at btyacc phaze.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
