Reconsider link-libraries
Opened this issue · 2 comments
Following up from discussion in slack. We agree that supporting link search paths and short names, ie -L/usr/lib -lfoo is more error prone than just supporting linking full paths, ie -l/usr/lib/libfoo.so. As a result we should probably drop the attribute link-libraries from the spec.
Revisiting this... what's the alternative? If my application currently links to /usr/lib64/libm.so, and nothing provides a CPS file (or, indeed, any way to import that as a component/target), how do I express that dependency to consumers? (Note that /usr/lib64/libm.so is still a link_libraries thing.)
On the one hand, it would be good if we could avoid those entirely (i.e. what we said in Slack). On the other, at least in CMake-land, I'm pretty sure INTERFACE_LINK_LIBRARIES sometimes has not-targets in it (in existing projects), and exporting those in some fashion is likely required for consumers to get something functional. That said, we can probably push for only supporting full paths.
Another point is that CMake at least has INTERFACE_LINK_DIRECTORIES separate from INTERFACE_LINK_OPTIONS. I feel like we ought to either support that explicitly in CPS as well, or else explicitly forbid its use from the CMake end if exporting to CPS. (My preference would be the latter, since we can relax that restriction in the future, but the other way around is far more problematic. We could similarly forbid non-absolute INTERFACE_LINK_LIBRARIES.)