Create extra symlinks for old SONAMES? #17
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For ELF targets, currently only one qualified SONAME is installed
libpvxs.so.0.1
. This doesn't capture the third (maintenance) version of a build. So far I've been able to avoid removing/changing symbols, so code linked against older libpvxs can run against a newer release. But I have added some, so this scheme doesn't fail well if the opposite happens, newer code against older libpvxs.I've wondering if a better way to handle this is to include the full version in the SONAME, and also create additional symlinks for older compatible releases?
eg. if I had done this so far, then a future 0.1.4 release would install
(I think in Mach-O land this would be expressed as
-current_version 0.1.4 -compatibility_version 0.1.0
)This PR an attempt to add some RULES to do this. eg. the preceding would be the result of:
COMPAT_VERSIONS = 0.1.0 0.1.1 0.1.2 0.1.3
@anjohnson Any thoughts on the ideas or method?