${linker_ld_file})
add_dependencies(ex2 linker.ld-target)
target_link_options(ex2 PRIVATE "-g" "LINKER:@${linker_ld_file}")
```
There’s a few other things in your example that I wouldn’t do that way or that I think are unnecessary, but those are unlikely to be related to your problem, so I’ll refrain from commenting on those so we can keep discussion focused on your problem.
---
### Author:  [@Barry\_Revzin](https://discourse.cmake.org/u/Barry_Revzin)
#### Post date: [September 8, 2023, 9:44pm UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/8 "2023-09-08T21:44:22Z")
> [@ClausKlein](#):
>
> IMHO: the CXX code is ugly?
This is quite rude. I do not care about your opinion about the quality of the C++ code that exists in this question solely to be a minimal reproduced example of the _build_ issue that I am trying to get resolved.
The comments you have added to this post are not even an attempt to answer my question. They have not been helpful.
---
### Author:  [@Barry\_Revzin](https://discourse.cmake.org/u/Barry_Revzin)
#### Post date: [September 8, 2023, 9:47pm UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/9 "2023-09-08T21:47:45Z")
Hi Craig! Thanks for the response.
I changed the CMakeLists.txt as you suggested - using absolute paths everywhere. In my real example, I was doing that already - this was a poor reproduction on my part. But doing so doesn’t resolve the issue. Even with absolute paths, `ex1` isn’t being updated when a change to `ex2.cxx` triggers a change to `linker.ld`.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 9, 2023, 12:35am UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/10 "2023-09-09T00:35:10Z")
I did some digging into this example with Ninja, and from what I can tell, the crux of the problem is that the executable targets end up with an order-only dependency on the `linker.ld-target` custom target. I think that explains why the first build works (no targets are up to date yet), but the second build after modifying ex2.cpp doesn’t cause ex1 to be relinked. That’s a bit of a guess on my part, but I couldn’t see any else immediately obvious which may explain the behavior.
This is getting a bit beyond my understanding of the nitty gritty details of the way dependencies are defined. We may need input from @brad.king on this one. I would have expected your example to work, but maybe there’s some subtle aspect of this I’m overlooking.
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [September 9, 2023, 10:08am UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/11 "2023-09-09T10:08:27Z")
> [@Barry\_Revzin](#):
>
> The comments you have added to this post are not even an attempt to answer my question. They have not been helpful.
## You didn’t explain your task you want to solve with your prototype.
Q: do you really need a linker `ld` file?
Q: does it has something to do with c++?
Q: should your solution only work on Linux?
Q: do you really need to count the lines in your main?
## My Example works on every build host with every c/c++ compiler, yours not!
I will try to explain my prototype:
You need a clear, simple dependency DAG.
If you really want to create a linker ld file, that depends on every source file in your project, then my example is also not right!
## But if you only want to link all your mains, if the ld file was updated, it works fine.
Simply touch an empty source file that will be linked to your mains.
```cmake
cmake_minimum_required(VERSION 3.24...3.27)
project(linking LANGUAGES CXX)
add_library(ex1-compiled OBJECT ex1.cxx)
add_library(ex2-compiled OBJECT ex2.cxx)
set(linker_ld_file ${CMAKE_CURRENT_BINARY_DIR}/linker.ld)
add_custom_command(
OUTPUT linker_generated.cxx ${linker_ld_file}
COMMAND python3 ${CMAKE_CURRENT_SOURCE_DIR}/gen_linker.py --dir ${CMAKE_CURRENT_SOURCE_DIR} >
linker_generated.cxx
COMMAND touch ${linker_ld_file}
DEPENDS ex1-compiled $ ex2-compiled $
)
add_executable(ex1 $ linker_generated.cxx)
target_link_options(ex1 PRIVATE "-g" "LINKER:@${linker_ld_file}")
add_executable(ex2 $ linker_generated.cxx)
target_link_options(ex2 PRIVATE "-g" "LINKER:@${linker_ld_file}")
```
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 10, 2023, 7:40am UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/12 "2023-09-10T07:40:30Z")
Let’s focus on the problem raised in the original post. That post does highlight that the example given was a “reduced and seemingly silly example”. We should expect that what has been presented isn’t meant to be the best way to achieve something, only that it is somehow representative of a problem in a larger, more complex project.
@Barry_Revzin So that we can refocus discussions here, can you please confirm that the main problem you’re asking about is that you expected the `gen_linker.py` script to be re-executed and both `ex1` and `ex2` to be re-linked if either `ex1.cxx` or `ex2.cxx` is modified, but you’re not seeing that occur and you’d like to understand why?
---
### Author:  [@Barry\_Revzin](https://discourse.cmake.org/u/Barry_Revzin)
#### Post date: [September 11, 2023, 1:34pm UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/13 "2023-09-11T13:34:42Z")
> [@craig.scott](#):
>
> Let’s focus on the problem raised in the original post. That post does highlight that the example given was a “reduced and seemingly silly example”. We should expect that what has been presented isn’t meant to be the best way to achieve something, only that it is somehow representative of a problem in a larger, more complex project.
Yes, exactly. Thank you.
> [@craig.scott](#):
>
> @Barry_Revzin So that we can refocus discussions here, can you please confirm that the main problem you’re asking about is that you expected the `gen_linker.py` script to be re-executed and both `ex1` and `ex2` to be re-linked if either `ex1.cxx` or `ex2.cxx` is modified, but you’re not seeing that occur and you’d like to understand why?
Yeah, that’s right. I made a cute mermaid diagram of the dependencies that I posted up top. Basically when `ex2.cxx` is updated, `ex2.o` needs to get rebuilt (this happens), and then `linker.ld` needs to get regenerated (this happens), and then `ex2` needs to get relinked with the new object file and the new linker file (this also happens) but `ex1` doesn’t get relinked even though `linker.ld` was updated.
A colleague pointed me to `LINK_DEPENDS` and this is where it gets a little weirder. Here’s a slightly longer version of the CMakeLists.txt file. I added two options, `ADD_DEP` and `SET_PROP`. `ADD_DEP=On SET_PROP=Off` is what my original example was doing:
```cmake
cmake_minimum_required(VERSION 3.24)
project(linking)
add_library(ex1-compiled OBJECT ex1.cxx)
add_library(ex2-compiled OBJECT ex2.cxx)
set(linker_ld_file ${CMAKE_CURRENT_BINARY_DIR}/linker.ld)
add_custom_command(
OUTPUT
${linker_ld_file}
COMMAND
python3 ${CMAKE_CURRENT_SOURCE_DIR}/gen_linker.py --dir ${CMAKE_CURRENT_SOURCE_DIR} > ${linker_ld_file}
DEPENDS
ex1-compiled $
ex2-compiled $
)
add_custom_target(linker.ld-target DEPENDS ${linker_ld_file})
add_executable(ex1 $ ${linker_ld_file})
target_link_options(ex1 PRIVATE "-g" "LINKER:@${linker_ld_file}")
add_executable(ex2 $ ${linker_ld_file})
target_link_options(ex2 PRIVATE "-g" "LINKER:@${linker_ld_file}")
option(SET_PROP OFF)
if(SET_PROP)
message(STATUS "Calling set_target_properties")
set_target_properties(ex1 PROPERTIES LINK_DEPENDS linker.ld-target)
set_target_properties(ex2 PROPERTIES LINK_DEPENDS linker.ld-target)
endif()
option(ADD_DEP OFF)
if(ADD_DEP)
message(STATUS "Calling add_dependencies")
add_dependencies(ex1 linker.ld-target)
add_dependencies(ex2 linker.ld-target)
endif()
```
Now, here is the behavior I see.
| Ninja | `ADD_DEP=Off` | `ADD_DEP=On` |
| --- | --- | --- |
| `SET_PROP=Off` | doesn’t compile (won’t build linker.ld) ❌ | builds but doesn’t relink ❌ |
| `SET_PROP=On` | works! ✔ | works! ✔ |
That setting both options to `Off` (top left) causes the initial build to fail makes sense - there’s no expressed dependency on `linker.ld` so it isn’t generated.
| Unix Makefiles | `ADD_DEP=Off` | `ADD_DEP=On` |
| --- | --- | --- |
| `SET_PROP=Off` | builds but doesn’t relink (???) ❌ | builds but doesn’t relink ❌ |
| `SET_PROP=On` | doesn’t build\* ❌ | doesn’t build\* ❌ |
I don’t understand this table. Setting both options to off still has the build succeed, despite not expressing the dependency on `linker.ld` anywhere. But if you add `set_target_properties`, _that’s_ when I get this failure:
```auto
make[2]: *** No rule to make target 'linker.ld-target', needed by 'ex1'. Stop.
make[1]: *** [CMakeFiles/Makefile2:171: CMakeFiles/ex1.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
```
And that’s regardless if you also add `add_dependencies()` or not.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 13, 2023, 7:27pm UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/14 "2023-09-13T19:27:11Z")
I suspect that’s due to the split view the Makefiles have of the whole build graph. FWIW, until we have a global graph for Makefiles as well (needed for reliable C++ modules support), I think it’d be OK to just say “use the Ninja generator” for now.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 13, 2023, 9:56pm UTC](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/15 "2023-09-13T21:56:53Z")
> [@ben.boeckel](#):
>
> …I think it’d be OK to just say “use the Ninja generator” for now.
Note that I was [seeing problems](https://discourse.cmake.org/t/dependency-not-being-respected-executable-not-being-relinked-when-necessary/8906/10) even with the Ninja generator.