0

I am trying to compile two executables foo and bar with cmake generating "Unix makefiles" under cygwin. Both executables are built from a single cmake project, so I have only a single CmakeLists.txt file.

The dependency between foo and bar is generated by an object file named depend.o, which is generated by the linker when linking foo.

I am able to tell cmake, that bar has an external dependency to a generated object file. I am also able to tell cmake that bar depends on foo, to get proper build order, but still the build fails when parallel builds are enabled.

This is what I did:

add_executable(bar .....)
add_executable(foo .....)
....
#Tell the linker we have an additional external library.
set_property(bar APPEND PROPERTY LINK_LIBRARIES "${CMAKE_CURRENT_BINARY_DIR}/depend.o")

#Tell cmake depend.o is a generated object file.
SET_SOURCE_FILES_PROPERTIES("${CMAKE_CURRENT_BINARY_DIR}/depend.o" PROPERTIES EXTERNAL_OBJECT true GENERATED true)

#And finally create dependency between the foo and bar
add_dependencies(bar foo)

So the question is: what trick is needed to get parallel builds work or how to properly define the dependency between foo and bar?

Edit: My question is not a duplicate of CMake: reuse object files built for a lib into another lib target. That question is about how to use the same object file in multiple libraries which can be done with "object libraries". I am after solving a dependency problem between two executables.

Foltos
  • 1
  • 1
  • @Tsyvarev: for me the object library feature mentioned by the linked question seems to solve a different problem. I am not sharing object files between multiple targets. One target generates it, and the another uses it. – Foltos Jun 19 '17 at 15:09
  • 1
    Hmm, so `depend.o` is **not** an object file generated from `depend.c` as a source file for target `foo`, is it? As for parallel build, `add_dependencies(bar foo)` unconditionally **forces build order**. So if `depend.o` is produced during building of `foo` executable, it should **exist** when building the `bar`. Or by `still the build fails when parallel builds are enabled.` do you mean something else? – Tsyvarev Jun 19 '17 at 16:43
  • I can not edit my previous message, so here is the full version: depend.o is generated by the linker while linking foo.elf. It has some special entry points of ARM trusted firmware. Regarding the dependency, I assumed the build order is forced, but this does not seems to be the case. I get a cmake error, for depend.o while foo is built. I can not run the build now because I don't have access to the license server, and thus I don't have the exact error message, but it was basically telling that cmake does not know how to build depend.o. – Foltos Jun 19 '17 at 21:00
  • On Stack Overflow you are free to delete your own comments when you find them wrong, incomplete, out-of-date, whatever. This is what differs comments from the post (question or answer). Well, lets wait the build message. – Tsyvarev Jun 19 '17 at 21:19
  • Unfortunately I fail to reproduce the problem since yesterday. Probably I mixed up something somehow (likely), or just the timing of the build changed and the problem is not triggered (unlikely). Anyways, thanks @Tsyvarev for your help! – Foltos Jun 20 '17 at 12:21
  • Just for being sure that problem has disappeared: Did you have a problem with **first build**, when `depend.o` wasn't exist yet? Or did you have a problem with **rebuilding**, when `depend.o` has been changed by building the `foo`, but `bar` didn't detect that change? – Tsyvarev Jun 20 '17 at 22:06

0 Answers0