Коллеги, а есть какой-то способ отследить последовательность включения #include-файлов? Компилирую LVGL

под ESP-IDF. Компилятор ругается на файлы ресурсов:

../components/menu_engine/interface_resources/battery_icon_charging_RGB565A8.c:29:30: error: unknown type name 'LV_ATTRIBUTE_LARGE_CONST' const LV_ATTRIBUTE_MEM_ALIGN LV_ATTRIBUTE_LARGE_CONST LV_ATTRIBUTE_IMG_BATTERY_
ICON_CHARGING uint8_t battery_icon_charging_map[] = {
^~~~~~~~~~~~~~~~~~~~~~~~
../components/menu_engine/interface_resources/battery_icon_charging_RGB565A8.c:6
2:7: error: unknown type name 'lv_img_dsc_t'
const lv_img_dsc_t battery_icon_charging = {
^~~~~~~~~~~~

Ну и так далее. Понятно - не может найти объявление типа. Типы, которые не может найти компилятор, определены в lv_img_buf.h.

lv_img_buf.h включается из lvgl.h.

В начале файла battery_icon_charging_RGB565A8.c есть такой код (с моими добавлениями):

#if defined(LV_LVGL_H_INCLUDE_SIMPLE)
#warning LVGL 1 included
#include "lvgl.h"
#else
#include "lvgl/lvgl.h"
#endif

#ifdef LV_IMG_BUF_H
#warning LV_IMG_BUF_H OK
#else
#error LV_IMG_BUF_H not defined
#endif // LV_IMG_BUF_H

Компилятор пишет следующее:

../components/menu_engine/interface_resources/battery_icon_charging_RGB565A8.c:
0:6: warning: #warning LVGL 1 included [-Wcpp]
#warning LVGL 1 included
^~~~~~~
../components/menu_engine/interface_resources/battery_icon_charging_RGB565A8.c:
9:2: error: #error LV_IMG_BUF_H not defined
#error LV_IMG_BUF_H not defined

То есть, в итоге, он как бы подключил lvgl.h, но файл lv_img_buf.h, который включается из lvgl.h, оказался не включен в battery_icon_charging_RGB565A8.c. Такое впечатление, как будто есть какое-то ограничение по глубине включения.

Никто не знает, в чем может быть дело?

Очень тупой тезис, но #include просто ж копипастит содержимое ровно туда, где он написан

Скорее или условное включение, или в каком-то хедере накосячили с одинаковыми ifndef в начале

Да. Но ВНЕЗАПНО тут оно не хочет так работать, как видно. Сам в офигении. Но вы таки не поверите - я добавил REQUIRES lvgl в CMakeLists для того компонента, в котором проблема. и ошибки пропали! Как работа #include завязана на CMakeLists - я ХЗ.

Скорее всего у тебя кеш у cmake без этой либы остался с прошлых его запусков (а может это барабашка).

Она собирается из исходников. Но блин, заголовочник-то должен искать сам компилятор, не?

Он его ищет по ключику -I и переменной среды INCLUDE

Не может он находить две разные версии?

Пути прописаны верно, все остальное находится и находит.

Там просто нет двух версий. :)

Ну значит "барабашка". Для изгнания барабашек используют шаманский бубен.

Когда юзаешь стороннее с глубоким внутренним миром, всегда есть шанс назвать свой файл дублирующим именем

lvgl для этого проекта я прикручивал сам ровно по той причине, что готовая сборка для ESP-IDF выглядит, эээ, странно.

cmake изобрёл новый термин — жопипаста когда рабочий код не работает

Ну, можно скомпилировать с -save-temps и посмотреть на результат работы препроцессора.