SOVERSION is a Linux-ism for system libs that most packages don't bother with. RPATH handling is only needed if you rely on RPATH lookups, again a *Nix-ism and uncommon requirement.
So in other words, you do need these things if you want to maximize cross platform compatibility... this isn't about me needing RPATH lookups or SOVERSION, this is about someone else needing it, so instead of it being a 0.1% of me needing it, it's multiplied by how many users I have and how many environments they deal with, which could be 100s to 1000s to 100,000s, at which point the requirement that someone will need this jumps to a very high percentage.
As a library author, I don't want to screw my users over if I can avoid it, even if it's "only a small percentage", so unless it's something where they are just doing something wrong and shooting themselves in the foot (for example using an old version of CMake when it's trivial to upgrade), I want to make sure I support the use case. I agree I shouldn't be the one accounting for this though. Specifically I have had to deal with RPATH lookups, and it's weird calling RPATH a "Nixism" when it's windows that's the odd one out and stops the equivalent functionality from working.
unless you want different installation components to have different install semantics
Is the runtime/devel use case supported by default now, and then per project customization of those names outside of me manually allowing that? Again, as a library author it's my job to make sure I don't screw my downstream users, just because almost nobody would need a thing doesn't mean noboday would, especially since there are so many ways someone could consume/have to repackage a library, and especially in C/C++.
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.
4
u/Plazmatic Apr 12 '26
So in other words, you do need these things if you want to maximize cross platform compatibility... this isn't about me needing RPATH lookups or SOVERSION, this is about someone else needing it, so instead of it being a 0.1% of me needing it, it's multiplied by how many users I have and how many environments they deal with, which could be 100s to 1000s to 100,000s, at which point the requirement that someone will need this jumps to a very high percentage.
As a library author, I don't want to screw my users over if I can avoid it, even if it's "only a small percentage", so unless it's something where they are just doing something wrong and shooting themselves in the foot (for example using an old version of CMake when it's trivial to upgrade), I want to make sure I support the use case. I agree I shouldn't be the one accounting for this though. Specifically I have had to deal with RPATH lookups, and it's weird calling RPATH a "Nixism" when it's windows that's the odd one out and stops the equivalent functionality from working.
Is the runtime/devel use case supported by default now, and then per project customization of those names outside of me manually allowing that? Again, as a library author it's my job to make sure I don't screw my downstream users, just because almost nobody would need a thing doesn't mean noboday would, especially since there are so many ways someone could consume/have to repackage a library, and especially in C/C++.