# Targets not available in other CMakeLists.txt (ESP-IDF)

**URL:** https://discourse.cmake.org/t/targets-not-available-in-other-cmakelists-txt-esp-idf/9439
**Category:** Usage
**Tags:** gen:ninja
**Created:** [November 16, 2023, 8:48am UTC](https://discourse.cmake.org/t/targets-not-available-in-other-cmakelists-txt-esp-idf/9439 "2023-11-16T08:48:16Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![itavero](https://discourse.cmake.org/user_avatar/discourse.cmake.org/itavero/32/2547_2.png) [@itavero](https://discourse.cmake.org/u/itavero)
#### Post date: [November 16, 2023, 8:48am UTC](https://discourse.cmake.org/t/targets-not-available-in-other-cmakelists-txt-esp-idf/9439/1 "2023-11-16T08:48:16Z")

</div>

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](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#using-esp-idf-in-custom-cmake-projects) 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

- libs
  - CMakeLists.txt

- products
  - my\_product
    - CMakeLists.txt

  - CMakeLists.txt

- 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.

---

<div class="post-metadata">

### Author: ![itavero](https://discourse.cmake.org/user_avatar/discourse.cmake.org/itavero/32/2547_2.png) [@itavero](https://discourse.cmake.org/u/itavero)
#### Post date: [November 16, 2023, 10:01am UTC](https://discourse.cmake.org/t/targets-not-available-in-other-cmakelists-txt-esp-idf/9439/2 "2023-11-16T10:01:47Z")

</div>

Looking [into the sources of the ESP-IDF](https://github.com/espressif/esp-idf/blob/v5.0.1/tools/cmake/component.cmake#L168) a bit more, I noticed that its actually an `IMPORTED` target and it seems to be missing the `GLOBAL` flag.  
I’ll see if adding that resolves the issue.

**Update** : this does seem to resolve the issue. I’ll open up an issue (or PR) on their GitHub repository.