# Build same lib with identical names in subninjas

**URL:** <https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296>\
**Category:** Code\
**Tags:** gen:ninja\
**Created:** [August 18, 2022, 2:49pm UTC](https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296 "2022-08-18T14:49:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![neuschwander\_lmi](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/n/76d3ee/32.png) [@neuschwander\_lmi](https://discourse.cmake.org/u/neuschwander_lmi)\
**Post date:** [August 18, 2022, 2:49pm UTC](https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296/1 "2022-08-18T14:49:27Z")

</div>

I am trying to create a build containing several cmake projects. Splitting the “whole” project into multiple cmake projects is necessary to support different C++ toolchains in one build.  
We use the ninja generator and have a main cmake file which runs “cmake” with `CMAKE_NINJA_OUTPUT_PATH_PREFIX=toolchainX` in multiple subdirectories of the main build. In general, this works fine and we can reference the files from the sub-builds as “toolchainX/fileX” from the main build.  
However, in some cases, cmake generates `cmake_object_order_depends_target_{target}` targets. From [https://gitlab.kitware.com/cmake/cmake/-/issues/20608#note\_739920](https://gitlab.kitware.com/cmake/cmake/-/issues/20608#note_739920) I read that these targets are generated basically if a `custom_command` does not properly list all `OUTPUT`s (please correct me if I’m wrong).  
The problem in this case is, that the `cmake_object_order_depends_target_{target}` are now defined multiple times, if the same target (e.g. a common shared library) is built in multiple subninjas. The “builds involving this target will not be correct” warning proves to be right in this case, and the build fails.

I see the following solutions:

1. List all outputs in `add_custom_command/target`. In our case, this is a problem, because the output is generated dynamically by a third-party tool which does not generate depfiles. This would be hell to maintain.
2. Add a new variable for a prefix/suffix for `cmake_object_order_depends_target_` analogous to CMAKE\_NINJA\_OUTPUT\_PATH\_PREFIX. This would probably need to be added for all target (as in non-file) names somehow.

Is there a solution for this problem with already-implemented tools? I searched for a prefix/suffix which is applied to all target names, but I found nothing.

I also tried using the “Ninja Multi-Config” generator and just use a different config for each sub-build. However, the Multi-Config generator does not seem to acknowledge CMAKE\_NINJA\_OUTPUT\_PATH\_PREFIX.

---

<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:** [September 8, 2022, 7:53pm UTC](https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296/2 "2022-09-08T19:53:00Z")

</div>

> [@neuschwander\_lmi](#):
>
> The problem in this case is, that the `cmake_object_order_depends_target_{target}` are now defined multiple times, if the same target (e.g. a common shared library) is built in multiple subninjas. The “builds involving this target will not be correct” warning proves to be right in this case, and the build fails.

Hrm. I suppose the prefix needs to be incorporated here. Do you mind filing [an issue](https://gitlab.kitware.com/cmake/cmake/-/issues) about this?

---

<div class="post-metadata">

**Author:** ![neuschwander\_lmi](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/n/76d3ee/32.png) [@neuschwander\_lmi](https://discourse.cmake.org/u/neuschwander_lmi)\
**Post date:** [September 12, 2022, 9:22am UTC](https://discourse.cmake.org/t/build-same-lib-with-identical-names-in-subninjas/6296/3 "2022-09-12T09:22:26Z")

</div>

[https://gitlab.kitware.com/cmake/cmake/-/issues/23953](https://gitlab.kitware.com/cmake/cmake/-/issues/23953)
