fix: cmake code generation of target_link_library

[tanneberger]

During my endeavors to build lingo, I encountered that cmake doesn't like mixing old and new target_link_libraries statements.

See: https://stackoverflow.com/questions/59522267/cmake-rejects-a-second-target-link-libraries-talking-about-keyword-vs-plain

target_link_libraries(my_prog PRIVATE foo bar)
target_link_libraries(my_prog baz)

[cmnrd]

Yep, we had this in reactor-c, too. However, it is problematic either way. If we merge this change, then all cmake-include's also have to specify the interface explicitly. Consequently, we break all examples and external LF code bases that link to additional libraries.

[edwardalee]

Can someone explain what this means? On this page, it says:

The PUBLIC, PRIVATE and INTERFACE scope keywords can be used to specify both the link dependencies and the link interface in one command.

Libraries and targets following PUBLIC are linked to, and are made part of the link interface. Libraries and targets following PRIVATE are linked to, but are not made part of the link interface. Libraries following INTERFACE are appended to the link interface and are not used for linking .

What is a "link interface" vs. a "link dependency"?

Also, once we know what the difference is, this documentation suggests that this could be replaced by two commands, thus avoiding this consistency problem.

[cmnrd]

PUBLIC, PRIVATE or INTERFACE are the link interfaces, what follows them are the dependencies that we want to link to using that particular interface.

Also, once we know what the difference is, this documentation suggests that this could be replaced by two commands, thus avoiding this consistency problem.

Could you point to that part of the documentation?

[cmnrd]

@tanneberger Is this blocking anything? If not, I would push this back for a bit down to the next release so that we can update the examples in sync with the release.

[tanneberger]

@cmnrd Its not blocking, I was just stumbling over it while writing on lingo.