Compilation STM32 HAL是否应作为预编译库包含

我有一个关于STM32L0的Keil STM32项目。我有时（比我想要的更多）必须更改包含路径或全局定义。这将触发对所有代码的完全重新编译，因为它需要“检查”由于这些更改而改变的行为。问题是：我没有必要更改HAL的相关参数，因此不需要（据我所知）完全重新编译这些文件。重新编译占用了相当多的时间，因为我包含了STM32L0的所有HAL驱动程序

一个好的做法是创建一个单独的项目，将HAL编译为一个库，并将其包含在我的主项目中吗？（当然，这将分别针对每个微控制器进行，因为它们具有不同的HAL）

问题不一定只对这个具体的例子有用，但这个例子为问题提供了一些范围

pps。对于不熟悉STM32 HAL的人。它是程序与底层硬件接口的标准化接口。它在

.c

和

.h

文件中提供，而不是STD/STL的预编译形式

更新

以下是需要在我的示例项目中管理的定义示例：

STM32L072xx，使用电路板，使用硬件驱动程序，区域，调试，跟踪

只有

STM32L072xx

和

DEBUG

对配置HAL库有用，因此当我将

跟踪

从定义更改为未定义时，不需要重新编译HAL。因此，在我看来，HAL可以单独管理

编辑

---

鉴于投票结果接近：我已经阅读了，我的问题旨在建设性地增加构建STM32程序的知识，并找到如何更有效地使用HAL库的最佳实践。我还没有发现任何关于将HAL构建为静态库的问题，因此这个问题至少是独一无二的。这个问题还需要一个丰富的答案，详细说明将HAL构建为一个单独的静态库的利弊。

这里的答案是。。视情况而定。正如评论中已经指出的，这取决于您计划如何管理您的项目。以公正的方式回答您的问题：

选项#1-在项目中直接使用HAL源意味着每次其（和底层）标题中的任何内容发生更改时都要重建HAL，这一点您已经注意到了。它的缺点是构建时间更长。好处-你确信你所建造的就是你所得到的

选项2-将HAL作为预编译的静态库。优点-更短的构建时间，缺点-您不能再绝对确定您包含的HAL库是否能按您所希望的方式工作。特别是，您需要以某种方式确保所有的

#define

与构建库时完全相同。这包括项目范围的定义（

DEBUG

，

STM32L072xx

等），以及HAL配置文件中的任何内容（

stm32l0xx_HAL_conf.h

）

看看你是一个怎样的Keil用户——也许这只是一个启用多核构建的问题？请参阅此链接：。HAL库并没有那个么大，所以在重建源文件时，构建时间应该是一个值得关注的问题

如果我要表达我的观点和经验——就我个人而言，我不会这么做，因为这可能会导致可靠性降低或副作用，这将很难诊断，并且随着您添加更多的源文件和更多类似的库，情况只会变得更糟。更不用说添加更多的人员来处理项目，并向他们解释他们“在更改给定的头文件集或项目范围的定义时，需要记住如何重建X库”

事实上，我所研究的代码库也遇到了同样的困境——它总共跨越了10k多个源文件和头文件，其中一些是特定于配置的，许多是共享的。它是高度模块化的，允许我们通过配置现有代码（主要是通过一组头文件）快速创建新的东西（硬件和软件方面）。然而，由于这种配置是通过标题完成的，因此对标题进行更改通常意味着重建项目的大部分。尽管构建时间有时很烦人，但出于上述原因，我们选择不创建静态库。对我个人来说，最好优先考虑可靠性，比如“我知道我在构建什么”

如果我想给出一些有助于避免在项目规模越来越大时进行重建的一般提示：

• 避免保存所有配置的全局标头。通常很容易将所有配置放在一个地方，在这个文件中为每个软件模块创建漂亮的注释和部分。这种方式更容易管理（直到该文件变得太大），但由于该文件非常常见，这意味着对其所做的任何更改都将导致完全重建。将这些文件拆分为与项目中每个模块相对应的单独标题

• 仅在需要时包含头文件。我有时会看到这样一种方法，即创建的头文件只“捆绑”其他头文件，这样的头文件稍后会包括在内。在这种情况下，对任何“较小”的头进行更改都会导致必须重新编译所有源文件，包括较大的文件。如果这样的文件不存在，那么只需要重新编译显式包含一个小头的源代码。显然，这里有一条线要画——包含太“低级别”的标题也可能不是最好的主意，例如，它们可能并不意味着作为内部库文件包含，可能随时会更改

• 在源文件中包含头文件优先于头文件。如果