12

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?

janitor048
  • 2,045
  • 9
  • 23
  • 29

2 Answers2

16

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:

target_link_libraries(A B C)

means target A requires libraries B and C.

If, instead, you consider case (2) above, where B depends on C, you would instead write:

target_link_libraries(B C)
target_link_libraries(A B)

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.

DLRdave
  • 13,876
  • 4
  • 53
  • 70
  • Sorry for being a bit vague: What I meant by "mutual dependence" are cases (2) and (3), I wasn't thinking of circular dependence. The thing is - as far as I understand the CMake documentation, putting all in one `target_link_libraries` command for cases (2) or (3) CMake would automatically recognize the dependence of e.g. B on C (in addition to A on C) and do the linking. Would that also work in cases (2) and (3) if I split it into two lines? – janitor048 Sep 01 '11 at 11:39
  • I edited my answer to add the "To clarify" section at the bottom. CMake does not recognize anything from "target_link_libraries(A B C)" other than that target A depends on libraries B and C. You must specify only directly dependent libraries. CMake will automatically link to indirectly mentioned libraries until the end of the dependency chain is reached. – DLRdave Sep 01 '11 at 13:45
  • @DLRdave In the case (2), is it possible to write `target_link_libraries(A B) target_link_libraries(B C)` other than `target_link_libraries(B C) target_link_libraries(A B)`? – John Oct 24 '22 at 03:51
  • It might be possible, but I don't know that it works in all situations, and in my opinion, it is not advisable. If you are going to say that A depends on B, then B must exist first, or at least, seems like it SHOULD exist first. And if it exists first, then it should already have expressed its dependencies, and if they include C, then that should exist before that point, too, and why not express it in the order of the dependencies? – DLRdave Oct 27 '22 at 17:03
4

Both ways are valid and equivalent. Basically target_link_libraries command just appends specified libraries to the LINK_INTERFACE_LIBRARIES property of the passed target (A in your sample).

Andrey Kamaev
  • 29,582
  • 6
  • 94
  • 88