search

cps-org / cps

Common Package Specification — A cross-tool mechanism for locating software dependencies
https://cps-org.github.io/cps/
Other
99 stars 8 forks source link

Reconsider link-libraries #51

Open tylerjw opened 6 months ago

tylerjw commented 6 months ago

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.

mwoehlke commented 2 months ago

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.)

mwoehlke commented 2 months ago

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.)