CMSIS 库是否应该包含在版本控制中? [英] Should CMSIS libraries be included in version control?

问题描述

通常，我曾经包含特定于设备的标头 &由芯片供应商 (ST) 和版本控制中的 CMSIS-Core 标头提供的源.数量不多，我也没有更新它们的习惯.我使用 STM32 微控制器，但不使用 CUBE 框架 或标准外设库.

Normally, I used to include device specific headers & sources provided by the chip vendor (ST) and CMSIS-Core headers in version control. There are not many of them and I didn't have a habit to update them. I use STM32 microcontrollers, but I don't use the CUBE framework or the Standard Peripheral Library.

最近，我需要使用 CMSIS-DSP 库.CMSIS-DSP 库带有大量的头文件和源文件.我决定使用大约 5.4 MB 的预编译库 (libarm_cortexM4lf_math.a).但现在我开始质疑他们是否应该进入版本控制.

Recently, I needed to use CMSIS-DSP libraries. CMSIS-DSP library comes with a large number of header and source files. I decided to use the precompiled library (libarm_cortexM4lf_math.a), which is around 5.4 MB. But now I started to question if they should go into the version control.

我知道在版本控制中管理二进制文件不是一个好主意.但据我所知，CMSIS 更新并不频繁.所以我很困惑.这些是我能想到的选项:

I know that managing the binary files in version control isn't a good idea. But as far as I know, CMSIS is not updated very often. So I'm confused. These are the options I can think of:

1. 在存储库中包含 CMSIS 标头和静态二进制文件: 如果我决定不更新这些库，这可能是个好主意.CMSIS 本身并不经常发布新版本，即使发布了新版本，也可能没有必要在项目中更新它.或者我可能会在我的项目中更新它之前跳过几个版本.
2. 在 repo 中包含 CMSIS 头文件和源文件: 与选项 1 类似，但 git 更愿意使用文本文件而不是 5 MB 以上的二进制文件.但我不确定让 3rd 方代码更改以污染我的源历史记录是否是个好主意(选项 1 遇到同样的问题，但只有头文件).
3. 不要在 repo 中包含 CMSIS: 这会导致一个干净的 repo，但是我必须在克隆项目后手动将库文件复制到项目目录中.我还可以为 CMSIS 指定一个系统范围的安装文件夹并将其添加到项目中，但它会导致 works-on-my-machine" 情况.
4. 找到一种自动获取库的方法:首先想到的是git submodules.但是，我不确定获取整个 CMSIS 存储库是否有效，因为我需要对其进行重构，因为有很多不需要的文件，包括预编译的二进制文件.我想我需要某种后期处理脚本?

1. Include CMSIS headers and static binaries in repo: It may be good idea if I decide not to update these libraries. CMSIS itself doesn't get new releases very often and even if a new version is released, it may not be necessary to update it in the project. Or I may skip a few releases before I update it in my project.
2. Include CMSIS header and source files in repo: Similar to option 1, but git will be happier to work with text files instead of a 5+ MB binary. But I'm not sure if letting 3rd party code changes to contaminate my source history is a good idea (Option 1 suffers the same problem, but header files only).
3. Don't include CMSIS in repo: This results in a clean repo, but then I have to manually copy library files into project directory after cloning the project. I can also specify a system wide installation folder for CMSIS and add it to the project but it causes a "works-on-my-machine" situation.
4. Find a way to fetch the library automatically: The first thing comes to mind is git submodules. However, I'm not sure if fetching the whole CMSIS repo will work, because I need to restructure it as there are lots of unneeded files, including precompiled binaries. I guess I need some kind of post processing script?

这里最好的方法是什么?还有其他选择吗?

What is the best approach here? Can there be other options?

这里有一个类似的问题:在源代码管理中存储第三方库 似乎人们对这个主题有不同的看法.但我相信在嵌入式 C 项目中使用 CMSIS 是一个具体案例，值得提出自己的问题.

There is a similar question here: Storing third-party libraries in source control It seems people have different opinions about the subject. But I believe using CMSIS in an embedded C project is a specific case and deserves its own question.

推荐答案

使用 CMSIS 的 IMO 嵌入式项目应该包含使用过的版本.CMSIS 不像 C 标准库那样标准化，而且新版本通常与旧版本不兼容.

IMO embedded projects which use CMSIS should have the used version included. CMSIS is not as standardized as C standard library and very often newer versions are not compatible with the older ones.

链接的帖子已有 12 年的历史，而且 (IMO) 回购的规模远没有当时那么重要.现在嵌入式程序员使用的计算机的存储、内存、计算能力和上行连接带宽都比不上12年前使用的计算机.

The linked post is 12 years old and (IMO) the size of the repo is far not as important as it was then. Storage, memory, computing power and uplink connection bandwidth of the computers used by the embedded programmers nowadays are not comparable to the computers used 12 years ago.

这篇关于CMSIS 库是否应该包含在版本控制中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！