Ответ здесь ... это зависит.Как уже указывалось в комментариях, это зависит от того, как вы планируете управлять своими проектами.Чтобы ответить на ваш вопрос непредвзято:
Вариант № 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 при изменении заданного набора файлов заголовков или определений проекта».
Фактически, мыМы столкнулись с той же дилеммой для кодовой базы, над которой я работаю - она охватывает в общей сложности более 10 тыс. исходных и заголовочных файлов, некоторые из которых зависят от конфигурации, а многие являются общими.Он очень модульный, что позволяет нам быстро создавать что-то новое (как аппаратное, так и программное), просто конфигурируя существующий код, в основном через набор заголовочных файлов.Однако, поскольку эта конфигурация выполняется с помощью заголовков, изменение в них обычно означает перестройку большой части проекта.Хотя время сборки иногда раздражает, мы отказались от создания статических библиотек по причинам, указанным выше.Лично для меня лучше расставить приоритеты в надежности, как в «Я знаю, что я строю».
Если бы мне нужно было дать какие-то общие советы, которые помогут избежать перестройки, когда ваш проект становится большим:
Избегайте глобальных заголовков, содержащих всю конфигурацию.Обычно заманчиво собрать всю конфигурацию в одном месте, создать красивые комментарии и разделы для каждого программного модуля в одном файле.Так проще управлять (пока этот файл не станет слишком большим), но поскольку этот файл настолько распространен, это означает, что любое изменение, внесенное в него, приведет к полной перестройке.Разделите такие файлы на отдельные заголовки, соответствующие каждому модулю в вашем проекте.
Включайте заголовочные файлы только там, где они вам нужны.Иногда я вижу подход, при котором создаются заголовочные файлы, которые только «связывают» другие заголовочные файлы, и такой заголовочный файл позже включается.В этом случае внесение изменений в любой из этих «меньших» заголовков приведет к необходимости перекомпиляции всех исходных файлов, включая файл большего размера.Если такого файла не существует, то нужно будет перекомпилировать только источники, явно включающие этот маленький заголовок.Очевидно, что здесь нужно провести черту - включая слишком «низкоуровневые» заголовки, возможно, и не самая лучшая идея, например, их не следует включать в файлы внутренней библиотеки, которые могут измениться в любое время.
Приоритетное включение заголовков в исходных файлах над файлами заголовков.Если у вас есть пара собственных файлов *.c (*.cpp) и *.h - скажем, temp_logger.c/.h, и вам нужен АЦП - тогда, если вам действительно не нужно какое-то определение АЦП в заголовке (что, скорее всего, не будет), затем включите файл заголовка ADC в файл temp_logger.c.В дальнейшем все файлы, использующие функции temp_logger, не нужно будет перекомпилировать в случае повторного построения HAL.