At work we are setting a single repository for all the embedded firmware for all our new platform products (targetting ARM Cortex-M33 MCUs as well as Espressifs ESP32-S3).
I’m currently trying to integrate their ESP-IDF (see the instructions in their documentation on using ESP-IDF in custom CMake projects).
The way we have structured our repository is roughly like this:
- mcu
- esp32_s3
- CMakeLists.txt
- CMakeLists.txt
- esp32_s3
- libs
- CMakeLists.txt
- products
- my_product
- CMakeLists.txt
- CMakeLists.txt
- my_product
- CMakeLists.txt
So, multiple directories and every directory has their own CMakeLists.txt. The level above includes that directory via add_subdirectory
.
If I include idf.cmake
in the same CMakeLists.txt as where I call idf_build_process
, it seems to work just fine.
However, if I call it from inside the mcu/esp32_s3/CMakeLists.txt
(which is processed before the product specific CMakeLists.txt), I get a lot of warnings about IDF component targets not being found.
These targets get created by including idf.cmake
(which includes some other modules and calls a macro/function to load all the components included in the ESP-IDF).
I added a message
statement next to the add_library
call inside the CMake script of the ESP-IDF and I see that this gets called for all the components I would expect.
If I do an if (NOT TARGET ___idf_app_trace)
check in mcu/esp32_s3/CMakeLists.txt
, it does not trigger the fatal error I have in it.
If I do the same one level above (so in mcu/CMakeLists.txt
, after the add_subdirectory
call of course), it does trigger.
Somehow the targets are not propagated correctly, but I never even knew that targets had a scope of sorts. I was always under the impression that targets would be available globally regardless of where they were defined.
So my questions:
How can it be that these targets are not available globally and how can I make it so that they are (while still including idf.cmake
from the MCU specific CMakeLists.txt)?
How can I now make these targets available globally?
I reckon this might actually need a change in the ESP-IDF scripts as well, so if I can understand what the problem is, I can probably provide them with a PR to improve on this as well.