通常，我曾经在版本控制中包含芯片供应商 (ST) 提供的设备特定标头和源以及 CMSIS-Core 标头。数量不多，也没有更新的习惯。我使用STM32微控制器，但我不使用立方体框架 or the 标准外设库.
最近，我需要使用CMSIS-DSP库。 CMSIS-DSP 库附带大量头文件和源文件。我决定使用预编译库 (libarm_cortexM4lf_math.a)，大约 5.4 MB。但现在我开始质疑它们是否应该进入版本控制。
我知道在版本控制中管理二进制文件不是一个好主意。但据我所知，CMSIS更新并不频繁。所以我很困惑。这些是我能想到的选项：
-
在存储库中包含 CMSIS 标头和静态二进制文件：如果我决定不更新这些库，这可能是个好主意。 CMSIS本身并不经常发布新版本，即使发布了新版本，也可能不需要在项目中更新它。或者，在我的项目中更新它之前，我可能会跳过一些版本。
-
在存储库中包含 CMSIS 头文件和源文件：与选项 1 类似，但是git会更乐意使用文本文件而不是 5+ MB 的二进制文件。但我不确定让第 3 方代码更改来污染我的源历史记录是否是一个好主意（选项 1 遇到同样的问题，但仅限于头文件）。
-
不要在存储库中包含 CMSIS：这会产生一个干净的存储库，但是在克隆项目后我必须手动将库文件复制到项目目录中。我还可以为 CMSIS 指定系统范围的安装文件夹并将其添加到项目中，但这会导致“在我的机器上运行”情况。
-
找到一种自动获取库的方法：第一个想到的是git 子模块。但是，我不确定获取整个 CMSIS 存储库是否有效，因为我需要重组它，因为有很多不需要的文件，包括预编译的二进制文件。我想我需要某种后处理脚本？
这里最好的方法是什么？还能有其他选择吗？
这里有一个类似的问题：在源代码管理中存储第三方库看来人们对这个话题有不同的看法。但我相信在嵌入式 C 项目中使用 CMSIS 是一个具体案例，值得单独提出问题。
使用 CMSIS 的 IMO 嵌入式项目应包含所使用的版本。 CMSIS 不像 C 标准库那样标准化，而且新版本通常与旧版本不兼容。
链接的帖子已经有 12 年历史了，（IMO）回购协议的规模远不如当时那么重要。现在嵌入式程序员使用的计算机的存储、内存、计算能力和上行连接带宽都无法与12年前使用的计算机相比。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
