Object Libraries - propagate target_link_libraries to final target
Continued discussion from : #18010 (closed)
So not sure how I can make a "compelling" use case for this, but my expectation for making object libraries "first class" citizens in CMake was that they would have the same features as other types of libraries.
Basic premise:
objlib1a <- (sources) + target_link_libraries(objlib1a1, objlib1a2, ...)
objlib1 <- (sources) + target_link_libraries(objlib1a, objlib1b, ...)
objlib2 <- (sources) + target_link_libraries(...)
lib1 <- (sources) + target_link_libraries(objlib1, ...)
dll1 <- (sources) + target_link_libraries(lib1, ...)
bin1 <- (sources) + target_link_libraries(lib1)
bin2 <- (sources) + target_link_libraries(dll1)
Currently this does not work as object libraries propagate their dependencies only to their immediate target. The concern raised was about ending up with duplicate symbols in the final link targets.
Duplicate symbols can occur with static libraries as well, but the linker will take the first occurrence found (pulling in the entire object containing that symbol). Which works fine if the symbols are actually true duplicates, but breaks (at runtime) if they are duplicates in name only. Caveat emptor.
With object libraries, CMake could mimic this behaviour by only adding an object to the link line if it isn't there already. Again, this prevents actual duplicate symbols, and breaks if a symbol is defined in different object files.
Forking, even privately, is not a good way to solve disagreements about proper behavior.
The reason I asked is that I've run out of time on this project, and I really -really- don't want to handcraft several hundred VS projects to resolve this. As I mentioned, I had hoped the upcoming object library improvements in CMake would duplicate the behaviour of real libraries with the added bonus of being able to link them into a final static library. Static libraries can't do that (at least with our toolchain) - they can only get linked into an executable or dynamic library.
It would only ever be a private fork unless the CMake community would like the patches. I'm more than happy to continue working with you on this, and hope my use-case is a compelling enough argument.