# Problems with interactions between $\<TARGET\_OBJECTS:lib\> and $\<$\<CONFIG:Debug\>:src.c\>

**URL:** https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058
**Category:** Code
**Tags:** gen:vs
**Created:** [November 25, 2024, 4:09pm UTC](https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058 "2024-11-25T16:09:04Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Glidos](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/fbc32d/32.png) [@Glidos](https://discourse.cmake.org/u/Glidos)
#### Post date: [November 25, 2024, 4:09pm UTC](https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058/1 "2024-11-25T16:09:04Z")

</div>

I’m combining libraries in a cmake-based project using:

```auto
    add_library(combined)
    target_sources(combined PRIVATE $<TARGET_OBJECTS:lib1> $<TARGET_OBJECTS:lib2>)

```

This in most cases works fine, but some of the source files for lib1 and lib2 have been speicified using `$<$<CONFIG:Debug>:src.c>`, and when using one of the vc++ generators in command-line-issued release builds, the conditional source files seem to get included in the target\_sources of the combined lib, although they are (as is correct) not built. That leads to a failed build.

Are there ways around this problem?

---

<div class="post-metadata">

### Author: ![Glidos](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/fbc32d/32.png) [@Glidos](https://discourse.cmake.org/u/Glidos)
#### Post date: [November 26, 2024, 11:24am UTC](https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058/2 "2024-11-26T11:24:47Z")

</div>

This gets stranger. Reversing the order of `$<TARGET_OBJECTS:lib1>` and `$<TARGET_OBJECTS:lib2`\> makes the build succeed. I’ve created a public gitlab repo showing this in the simplest form I can: [Glidos Public / cmake-target-objects-failure · GitLab](https://gitlab.com/glidos-public/cmake-target-objects-failure). The head of master shows the failure. One commit back is the succeeding version. It’s an entirely trivial example. I’ve provided a build.bat file so there is no uncertainty in the commands being used.

---

<div class="post-metadata">

### Author: ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)
#### Post date: [November 26, 2024, 12:33pm UTC](https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058/3 "2024-11-26T12:33:40Z")

</div>

Have you tried making `lib1` and `lib2` into `OBJECT` libraries? It was `OBJECT` libraries for which `TARGET_OBJECTS` was originally intended. I have no idea whether it can help, but it’s something I’d try if this was happening to me.

---

<div class="post-metadata">

### Author: ![Glidos](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/fbc32d/32.png) [@Glidos](https://discourse.cmake.org/u/Glidos)
#### Post date: [December 1, 2024, 8:04pm UTC](https://discourse.cmake.org/t/problems-with-interactions-between-target-objects-lib-and-config-debug-src-c/13058/4 "2024-12-01T20:04:38Z")

</div>

I didn’t try making `lib1` and `lib2` into `OBJECT` libraries. I will give that a try just to find out whether it makes a difference, but it may be not ideal because I have other builds where I need the individual libraries and I’d rather not add more conditions to handle the different cases.

Anyway, I do now have a workaround. If I split up the definitions like this:

```auto
add_library(combined)
target_sources(combined PRIVATE $<TARGET_OBJECTS:lib1>)
target_sources(combined PRIVATE $<TARGET_OBJECTS:lib2>)

```

both orders in which I add the two libraries then work. If you’re wondering why I care about being able to use both orderings, it’s because this is a very simplified version of my actual project. In my actual project there are around 400 libraries, and I derive the list programatically.