CMAKE: Circular ... dependency dropped - cmake

Question

I have a 3rd-party (prebuilt) executable (named other) located in imported folder of my project's source tree. Basically, the project's structure looks like this:
.
├── CMakeLists.txt
├── imported
│   ├── libother.so
│   └── other
└── main.cpp
In order for my application to operate properly, that other executable must be copied next to my executable, what I achieve with this script:
cmake_minimum_required(VERSION 3.21)
project(myproject)
add_executable(myexe main.cpp)
set(path_in ${CMAKE_SOURCE_DIR}/imported/other)
set(path_out ${CMAKE_BINARY_DIR}/other)
add_executable(other_i IMPORTED)
set_target_properties(other_i PROPERTIES IMPORTED_LOCATION ${path_in})
add_custom_command(OUTPUT ${path_out}
COMMAND ${CMAKE_COMMAND} -E copy ${path_in} ${path_out}
DEPENDS other_i
)
add_custom_target(other DEPENDS ${path_out})
add_dependencies(myexe other)
The problem is whenever the project is being built, on Linux, I am getting weird messages from gmake:
$ cmake -S . -B .build
...
$ cmake --build .build
gmake[2]: Circular CMakeFiles/other <- other dependency dropped.
gmake[2]: Circular other <- other dependency dropped.
While the other is copied all right, it is being copied ALWAYS whenever I re-issue a build command (even without any changes). This is undesirable and what is bothering me most is that it works perfectly with MSVC on Windows and also with shared libraries on Linux. E.g. this works fine:
cmake_minimum_required(VERSION 3.21)
project(myproject)
add_executable(myexe main.cpp)
set(path_in ${CMAKE_SOURCE_DIR}/imported/libother.so)
set(path_out ${CMAKE_BINARY_DIR}/libother.so)
add_library(other_i SHARED IMPORTED)
set_target_properties(other_i PROPERTIES IMPORTED_LOCATION ${path_in})
add_custom_command(OUTPUT ${path_out}
COMMAND ${CMAKE_COMMAND} -E copy ${path_in} ${path_out}
DEPENDS other_i
)
add_custom_target(other DEPENDS ${path_out})
add_dependencies(myexe other)
I am at wits end on what is going on. Is it a CMAKE's bug or I am missing something?
Any insights would be greatly appreciated.
PS: Please do not suggest using POST_BUILD on a main target, as this approach has it's own drawbacks.

Answer 1

The line
add_custom_target(other DEPENDS ${path_out})
creates a dependency of other from the ${CMAKE_BINARY_DIR}/other.
But from the view of Make these are the same things: both refers to the file other under the build directory (where Makefile is located). Because of that you get the message
gmake[2]: Circular other <- other dependency dropped.
The core of the problem is that unlike to CMake, Make doesn't have separation of targets (pure names) and files (located on the disk). From the view of Make all targets (even .PHONY ones) are files.
Using another name for target other (e.g. other_exe) would eliminate the problem.

Answer 2

This appears to be a bug in CMake! I worked around it like this:
cmake_minimum_required(VERSION 3.21)
project(myproject)
set(path_in "${CMAKE_CURRENT_SOURCE_DIR}/imported/other")
set(path_out "${CMAKE_CURRENT_BINARY_DIR}/other")
add_custom_command(
OUTPUT "${path_out}"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different "${path_in}" "${path_out}"
DEPENDS "${path_in}"
)
add_custom_target(other_update DEPENDS "${path_out}")
add_executable(myproject::other IMPORTED)
set_target_properties(myproject::other PROPERTIES IMPORTED_LOCATION "${path_out}")
add_dependencies(myproject::other other_update)
add_executable(myexe main.cpp)
add_dependencies(myexe myproject::other)
There were a couple other issues with specifying your dependencies, so I cleaned those up. Even so, I observe that naming an executable target (even if imported) the same as the output file trips the bug. You should open an issue with CMake upstream.
In general, it is a good idea to utilize the fact that CMake always treats names containing :: as target names.