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. 在回购中包含CMSIS标头和源文件:与选项1相似，但是 git 将更适合处理文本文件，而不是5 MB以上的二进制文件.但是我不确定让第三方代码更改来污染我的源历史记录是否是个好主意(选项1遇到相同的问题，但仅是头文件).
3. 在回购中不包含CMSIS::这将产生干净的回购，但是克隆项目后，我必须手动将库文件复制到项目目录中.我还可以为CMSIS指定系统范围的安装文件夹，并将其添加到项目中，但这会导致我的机器上工作" 情况.
4. 找到一种自动获取库的方法:首先想到的是 git子模块.但是，我不确定获取整个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屋！