源码使用问题

1. grammar.ypp是使用EBNF语言编写的语法规则文件, 因为EBNF严格来说并不是编程语言, 也比较小众所以难以理解是正常的, 此文件使用GNU/bison工具可以转为C语言源码, 这份转出来的C语言源码是可以直接与其余部分的代码编译链接到一起的, 你可以发现我在C++代码里调用了一个名叫yyparse的C语言函数, 这里实际上就是bison输出的C代码的入口点, 用于启动语法分析器建立语法树

下面这里面的grammar.cpp就是从grammar.ypp转出来的, scanner.cpp同理, 因为这个文件经常会更新所以把它放在构建目录下, 并且不提交到git, 你说的这个问题最简单的解决办法就是把这俩文件也提交到git, 这样的话环境里没有flex/bison理论上说也能编译过, 但是要改cmake, 因为flex和bison的转换也是编译流程里的一环, 需要把这一步去掉
![build文件夹](https://foruda.gitee.com/images/1711335256933119966/ad36a4db_7674940.png "屏幕截图")
但是有个问题就是, 如果你想改语法规则, 你只能通过改EBNF来实现, 手改bison输出的代码是非常难的, 所以最后还是需要装bison这个工具, 而且这两个文件严格来说也属于编译流程中产生的中间文件, 就像是QT MOC输出的文件一样, MOC的输出也不会提交到git, 基于以上考虑才把这俩文件排除到git之外的

cmake里在这里添加了fiex和bison的转换步骤, 并且作为源码的依赖项
![cmake](https://foruda.gitee.com/images/1711335512949399223/de3b623e_7674940.png "屏幕截图")

2. 把编译器和计算器两个组件做成dll, 不是不行, 但这不符合git的源码控制的理念, dll不是纯文本文件, 如果需要进行两个版本之间的差异和改动的对比就无能为力了, 我目前其实有类似的想法, 但是不是做成dll, 而是把编译器组件做成单独的exe, 在另一个仓库里维护, 计算器组件和程序主体以及编译器两边耦合的都很深所以可能还得做些结构性的改进才能独立出来, 总的来说这个改动不是一时半会能做完的

针对环境配置的问题, 你可以看下这些文档, 理论上说环境配置也只包括QT和flex/bison这三项, 并没有太复杂的环境, 相对于正常QT开发环境而言也只是多了flex和bison这两个工具而已
https://gitee.com/finalize/signal-test-box#9-%E6%9E%84%E5%BB%BA%E6%BA%90%E7%A0%81
https://gitee.com/finalize/signal-test-box/blob/master/build_project.md

ZZH-Finalize/信号实验箱

内容风险标识

评论 (1)

ZZH-Finalize/信号实验箱 .gitee-modal { width: 500px !important; }

内容风险标识