我有一个用于STM32L0的Keil STM32项目。我有时（比我想要的更多）不得不更改包含路径或全局定义。这将触发所有代码的完全重新编译，因为由于这些更改，它需要“检查”更改的行为。问题是：我不必更改HAL的相关参数，因此（据我所知）不需要完全重新编译这些文件。由于我为STM32L0包括了所有的HAL驱动程序，因此重新编译需要花费大量时间。
一个好的做法是创建一个单独的项目，将HAL编译为一个库并将其包含在我的主项目中吗？ （这当然将针对每个具有不同HAL的微控制器分别完成。）
ps。该问题并不一定只对这个特定示例有用，但是该示例为该问题提供了一定范围。
pps。适用于不熟悉STM32 HAL的人。它是程序与基础硬件进行交互的标准接口。它以.c和.h文件的形式提供，而不是STD / STL的预编译形式。
更新
以下是我的示例项目中需要管理的定义的示例：
STM32L072xx,USE_B_BOARD,USE_HAL_DRIVER, REGION_EU868,DEBUG,TRACE
只有STM32L072xx和DEBUG对于配置HAL库很有用，因此当我将TRACE从已定义更改为未定义时，不需要重新编译HAL 。因此在我看来，HAL可以单独管理。
修改
人们已经投票赞成：我读过don't ask section，我的问题是寻求建设性地增加构建STM32程序的知识，并找到如何更有效地使用HAL库的最佳实践。 。我还没有找到关于将HAL构建为静态库的任何问题，因此至少可以将其视为唯一的问题。这个问题也意在邀请一个丰富的答案，详细说明将HAL构建为单独的静态库的利弊。
答案 0 :(得分：3)
答案是..这取决于。正如评论中已经指出的那样，这取决于您计划如何管理项目。要以公正的方式回答您的问题：
选项＃1-在您的项目中直接拥有HAL源意味着您已经注意到，只要其（和底层）标头中的任何内容发生变化，都将重建HAL。缺点是构建时间较长。好处-您确定自己所创造的就是您所得到的。
选项2-使用HAL作为预编译的静态库。上行-缩短构建时间，下行-您不再可以完全确定所包含的HAL库是否按预期运行。特别是，您需要以某种方式确保所有#define与构建库时完全相同。这包括项目范围的定义（DEBUG，STM32L072xx等），以及HAL配置文件中的任何内容（stm32l0xx_hal_conf.h）。
了解您如何成为Keil用户-也许仅仅是启用多核构建的问题？请参见以下链接：http://www.keil.com/support/man/docs/armcc/armcc_chr1359124201769.htm。 HAL库并不大，以至于在重建其源文件时应该考虑构建时间。
如果我要表达自己的观点和经验-就我个人而言，我不会这样做，因为这可能会导致可靠性或副作用降低，这将很难诊断，并且只会在添加更多源文件和情况时变得更糟。像这样的更多图书馆。更不用说增加更多的人来从事该项目，并向他们解释他们“在改变给定的头文件或项目范围的定义时，需要记住重建X库”。
实际上，对于我正在研究的代码，我们遇到了同样的难题-它总共涵盖了超过1万个源文件和头文件，其中一些是特定于配置的，并且许多是共享的。它是高度模块化的，这使我们能够仅通过配置现有代码（主要是通过一组头文件）来快速创建新的东西（包括硬件和软件）。但是，由于此配置是通过标题完成的，因此更改标题通常意味着重建项目的很大一部分。尽管有时构建时间很烦人，但出于上述原因，我们还是选择不制作静态库。就我个人而言，最好将可靠性放在首位，例如“我知道我在建造什么”。
如果我要提供任何一般性提示，以帮助避免在项目规模较大时进行重建：
避免保留所有配置的全局头。通常很容易将所有配置都放在一个位置，在这个文件中为每个软件模块创建漂亮的注释和部分。这样管理起来比较容易（直到该文件变得太大），但是由于该文件太常见了，这意味着对该文件所做的任何更改都将导致完全重建。将此类文件拆分为与项目中每个模块相对应的标头。
仅在需要头文件的地方包括它们。有时，我看到一种创建头文件的方法，该头文件仅“捆绑”其他头文件，并且稍后包含此类头文件。在这种情况下，更改任何“较小”标头中的任何一个将具有必须重新编译包括较大文件在内的所有源文件的效果。如果这样的文件不存在，则只需要重新编译显式包含一个小头的源即可。显然，这里要划定一条线-包括太“低级”的标题可能也不是最好的主意，例如它们可能并不意味着会作为内部库文件包含在内，并且随时可能更改。
将头文件中的头文件优先于头文件。如果您有一对自己的*.c（*.cpp）和*.h文件-假设temp_logger.c/.h并且需要ADC-除非您确实需要一些ADC定义标头（您可能不会），然后将ADC标头文件包含在temp_logger.c文件中。稍后，无需重新编译所有使用temp_logger函数的文件，以防再次重建HAL。
答案 1 :(得分：0)
我的看法是，将HAL构建到一个库中。更快的构建时间所带来的好处超过了磁带库过时的风险。在项目初期的某个阶段过后，对我来说，改变会影响HAL的东西并不寻常。但是更快的构建时间会带来很多回报。
我创建了一个多项目工作区，其中一个项目用于HAL库，另一个项目用于引导加载程序，而另一个项目用于应用程序。开发时，我只重建应用程序项目。进行发布构建时，选择“项目”->“批量构建”，然后重新构建所有三个项目。这样，发行版本的构建将始终使用所有最新的代码和构建设置。
此外，在“目标选项”对话框的“输出”选项卡上，取消选中“浏览信息”将大大减少构建时间。