Say I have a target A that depends on the libraries B and C. But B and C have no mutual dependence. The linking with CMake could look like
target_link_libraries( A B C )
but
target_link_libraries( A B )
target_link_libraries( A C )
also seems to work (and might be more easy to maintain). Are there disadvantages of splitting the target_link_libraries command into multiple commands? Or should one always put it into a single command in case one eventually does encounter a mutual dependence of the libraries?
Those are exactly equivalent. Both say that A depends on B and A depends on C. Neither says anything about any dependency between B and C, so there is none.
I’m not sure what you mean by “mutual dependence” — when considering B and C, there are 4 possibilities: (1) neither depends on the other, (2) B depends on C, (3) C depends on B, or (4) they both depend on each other.
(1) is what you have. (2) and (3) would mean you should add another target_link_libraries command with either “B C” as the args or “C B” respectively. (4) means you have a circular dependency and they really shouldn’t be separate libraries at all, but combined into a single logical entity. You should avoid (4) because it makes it impossible to load as shared libraries on some (all?) platforms.
There is negligible performance penalty for having two separate target_link_libraries calls. I doubt you could measure the performance and show any significant timing differences.
To clarify, this call:
means target A requires libraries B and C.
If, instead, you consider case (2) above, where B depends on C, you would instead write:
which means target B requires library C, and target A requires library B (and CMake automatically transitively propagates B’s dependencies to A so that you do not have to know about any A -> C dependence unless you have explicit code that calls functionality in library C).
You should always express the minimum dependency information necessary to link things together.