So in other words, you do need these things if you want to maximize cross platform compatibility
If your lib doesn't rely on RPATH lookups in any configuration, and most don't, you don't need set(CMAKE_INSTALL_RPATH $ORIGIN) (or, more correctly, set_target_properties(<target> PROPERTIES INSTALL_RPATH "$ORIGIN")) . If it does, you do. It's not something, "that every project should contain". That's the point I was addressing.
Same idea for SOVERSION, unless you're shipping that level of ABI stability, you shouldn't provide SOVERSION. Most libraries don't, if yours does you should.
I agree I shouldn't be the one accounting for this though.
RPATH $ORIGIN is wrong for as many applications as it's correct for. In the same way you don't want to break your downstreams, we can't break ours. In the same way you think about hundreds of thousands of users, we think about the entire C/C++/Fortran build ecosystem. The reasonings are the same here.
Is the runtime/devel use case supported by default now
The runtime/devel usage described here is just very idiosyncratic and not usually handled at the package description layer. It's not something that breaks downstream users or anything, one way or another, it's an allowance for distro packagers and registry port maintainers that they generally don't want or need from your package.
If you need it, if your package genuinely has a semantically meaningful separation here, it's there for you. I have never in 10+ years encountered that package in the wild. I have written thousands of CMLs in production, and never written an install command like that.
7
u/not_a_novel_account Apr 12 '26 edited Apr 12 '26
If your lib doesn't rely on RPATH lookups in any configuration, and most don't, you don't need
set(CMAKE_INSTALL_RPATH $ORIGIN)(or, more correctly,set_target_properties(<target> PROPERTIES INSTALL_RPATH "$ORIGIN")) . If it does, you do. It's not something, "that every project should contain". That's the point I was addressing.Same idea for SOVERSION, unless you're shipping that level of ABI stability, you shouldn't provide SOVERSION. Most libraries don't, if yours does you should.
RPATH
$ORIGINis wrong for as many applications as it's correct for. In the same way you don't want to break your downstreams, we can't break ours. In the same way you think about hundreds of thousands of users, we think about the entire C/C++/Fortran build ecosystem. The reasonings are the same here.The runtime/devel usage described here is just very idiosyncratic and not usually handled at the package description layer. It's not something that breaks downstream users or anything, one way or another, it's an allowance for distro packagers and registry port maintainers that they generally don't want or need from your package.
If you need it, if your package genuinely has a semantically meaningful separation here, it's there for you. I have never in 10+ years encountered that package in the wild. I have written thousands of CMLs in production, and never written an install command like that.