是否应该在版本控制中包括CMSIS库？

Question

通常，我经常在版本控制中包括设备特定的报头&由芯片供应商(ST)和CMSIS报头提供的源。他们并不多，我也没有更新他们的习惯。我使用STM32微控制器，但我不使用多维数据集框架或标准外设库。

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

我知道在版本控制中管理二进制文件不是一个好主意。但据我所知，CMSIS并不经常更新。所以我很困惑。以下是我能想到的选择：

1. Include CMSIS和repo:中的静态二进制文件--如果我决定不更新这些库，可能是个好主意。CMSIS本身并不经常获得新版本，即使发布了新版本，也可能没有必要在项目中对其进行更新。或者，在我的project.
2. Include CMSIS头文件和与选项1类似的repo:中的源文件中更新它之前，我可能会跳过几个版本，但是git更喜欢使用文本文件而不是5+ MB二进制文件。但我不确定让第三方代码更改来污染我的源代码历史是否是个好主意(选项1也遇到了同样的问题，但是头文件only).
3. Don't在repo:中包含CMSIS )--这会导致一个干净的回购，但是在克隆项目之后，我必须手动地将库文件复制到项目目录中。我还可以为CMSIS指定一个系统范围的安装文件夹，并将其添加到项目中，但它会导致一个“works”situation.
4. Find (一种自动获取库的方法)：首先想到的是git子模块。但是，我不确定获取整个CMSIS是否有效，因为我需要重新构造它，因为有很多不需要的文件，包括预编译的二进制文件。我想我需要某种后处理脚本？

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

这里有一个类似的问题：Storing third-party libraries in source control，似乎人们对这个问题有不同的看法。但我认为，在嵌入式C项目中使用CMSIS是一个具体的案例，值得提出自己的问题。

Answer 1

使用CMSIS的IMO嵌入式项目应包括已使用的版本。CMSIS没有C标准库那么标准化，而且更新的版本常常与旧版本不兼容。

连系职位已有12年历史，而(国际海事组织)回购计划的规模远不如当时重要。现在嵌入式程序员使用的计算机的存储、内存、计算能力和上行连接带宽都无法与12年前的计算机相媲美。