# Need correct CMake “$\<TARGET\_NAME:” usage to enable cross-export set INTERFACE\_LINK\_LIBRARY dependencies

**URL:** <https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772>\
**Category:** Code\
**Created:** [February 16, 2021, 3:42pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772 "2021-02-16T15:42:49Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![chissg](https://discourse.cmake.org/user_avatar/discourse.cmake.org/chissg/32/1207_2.png) [@chissg](https://discourse.cmake.org/u/chissg)\
**Post date:** [February 16, 2021, 3:42pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/1 "2021-02-16T15:42:49Z")

</div>

I have a target in an export set—`plugins::support_macros`, say—that has an interface link dependence on a target in a different export set in the same package (_e.g._ `libs::main_lib`). I understand that I need to express the dependency using `$<TARGET_NAME:...>`, but it keeps getting interpreted too early and I get, “The following imported targets are referenced, but missing:…”

Attempts to delay interpretation of the generator expression result either in raw and unhelpful `\` characters in the `Targets.cmake` file, or in CMake not recognizing the target at build time. My closest attempt so far is to express the dependence as:

```cmake
target_link_libraries(support_macros INTERFACE $<1:$<TARGET_NAME:libs::main_lib>> ...)

```

This ends up in the `Targets.cmake` as:

```cmake
...INTERFACE_LINK_LIBRARIES "\$<1:libs::main_lib>;..."

```

and the subsequent check fails:

```auto
unset(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE_targets)
foreach(_target "lib::main_lib" )
  if(NOT TARGET "${_target}" )
    set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE_targets "${${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE_targets} ${_target}")
  endif()
endforeach()

```

I’m at my wits’ end here: the documentation for `$<TARGET_NAME:...>` on CMake’s generator expressions page is terse, and finding search terms that don’t just return links to it from all over the internet has been impossible for me thus far.

Any help appreciated!

[PS] I have seen [https://stackoverflow.com/questions/36103012/cmake-dependency-management-in-a-multi-library-package-export](https://stackoverflow.com/questions/36103012/cmake-dependency-management-in-a-multi-library-package-export), but it does not appear to address my problem.  
[PPS] This is with CMake 3.18.2

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [February 16, 2021, 8:21pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/2 "2021-02-16T20:21:49Z")

</div>

Your problem is not that `$<TARGET_NAME>` is helping or hurting. The problem is that your export sets must be included in their dependency order. So the export containing `libs::main_lib` must be included from your `config.cmake` file before the export containing `plugins::support_macros`.

---

<div class="post-metadata">

**Author:** ![chissg](https://discourse.cmake.org/user_avatar/discourse.cmake.org/chissg/32/1207_2.png) [@chissg](https://discourse.cmake.org/u/chissg)\
**Post date:** [February 16, 2021, 9:11pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/3 "2021-02-16T21:11:42Z")

</div>

Thanks for this. Given the somewhat cryptic explanation for `$<TARGET_NAME:...>` in the documentation, I’d allow myself to believe that it could be used as a placeholder to allow the order of inclusion of the targets files to not matter. Given the logical, rather than physical nature of export sets, this seemed like a reasonable feature to expect.

I’m incorporating modern CMake paradigms into a package that allows non-expert scientists to code their own software without becoming CMake experts, and a large part of that task is autogenerating the config and target files to do (almost) everything our scientists want without requiring hand-rolling. It’s relatively straightforward to detect a dependency from another export set and wrap it; less so to ensure that the contents of the export sets (as specified by non-experts) follow a strict dependency hierarchy.

Oh well, time to look for a different approach.

Thanks for taking the time to give me the bad news rather than letting me dig on in ignorance.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [February 16, 2021, 9:28pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/4 "2021-02-16T21:28:37Z")

</div>

I wouldn’t give too much power over export sets to developers if you’re trying to do something like this. On the other hand, for the size of the task you’re looking for, [VTK’s module system](https://gitlab.kitware.com/vtk/vtk/blob/master/CMake/vtkModule.cmake) is on the order of the complication you’re going to end up with. Note that you can probably rip out various parts of it, but things like `vtk_module_find_package` and `vtk_module_scan`/`vtk_module_build` are immensely helpful with gathering the required information from the project.

---

<div class="post-metadata">

**Author:** ![chissg](https://discourse.cmake.org/user_avatar/discourse.cmake.org/chissg/32/1207_2.png) [@chissg](https://discourse.cmake.org/u/chissg)\
**Post date:** [February 16, 2021, 9:36pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/5 "2021-02-16T21:36:54Z")

</div>

Great, thank you for the extra information.

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [March 18, 2021, 6:39am UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/6 "2021-03-18T06:39:25Z")

</div>

@ben.boeckel Can you suggest some improved wording for the `$<TARGET_NAME:...>` generator expression documentation? It currently says “This is required if exporting targets to multiple dependent export sets”, but it doesn’t say why. Some sort of example would really help, but I don’t really understand the use of this even after looking at its C++ implementation (which does nothing but unconditionally return the target name anyway, so I don’t know what it is affecting). Having arrived here myself after another export-related problem in a different project but with similar error message, it is apparent that we need to make it clearer what problems `$<TARGET_NAME:...>` does and does not solve.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [March 18, 2021, 1:18pm UTC](https://discourse.cmake.org/t/need-correct-cmake-target-name-usage-to-enable-cross-export-set-interface-link-library-dependencies/2772/7 "2021-03-18T13:18:01Z")

</div>

My understanding is that `$<TARGET_NAME>` is there so that CMake can pull a target name out of an arbitrary genex without evaluating it. I really don’t know the provenance of that statement in the documentation. It looks to come from the commit adding the expression, so it’s been there from the beginning (`b0c8f73eb6 (Add the TARGET_NAME generator expression., 2012-12-10)`). I don’t know if things got confused or what, but the commit message mentions its use as a preprocessing marker as well.