Proper shared library handling for the C++ bindings

[darix]

Feature Request

Proposed Change to existing Behavior

Description

1. right now libopentime.so and libopentimelineio.so are lacking an soversion. it would be nice to assign a proper soversion for those.
2. allow the python extensions to use the shared library.

Context

This would make it easier to package OpenTimelineIO and use it with other programs olive.

[meshula]

This would be a welcome PR!

It's a more complex request that it appears on first blush though, so I'd like to lay out what I'd hope to see in a PR:

For maintainers for whom SO version policy is not their day job, it is extraordinarily difficult to make sense of the SO versioning documentation. On other projects, SO versioning has been a bit of a challenge, as we've frequently got, sometimes urgent, "you messed it up" issues, but very few "here's how to do it right" PRs or comments leaving the maintainers in the frustrating position of attempting to iterate fixes and wait for validation.

I am aware of pages like this https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, or https://www.debian.org/doc/debian-policy/ch-sharedlibs.html, but these pages are filled with caveats, like "some" or "most" and "normally." I'd like to see something specific to OTIO with OTIO's policy explicitly laid out.

On that note, I request that any PR introducing SO version should please also include

• additions to the documentation that describe clearly a policy on when and how SO version is to be updated; something along the lines of "when this condition is met, modify the SO version as follows" for whatever unique combinations of conditions and actions exist.

• required naming conventions for Python per platform,

• required naming conventions for Linux, and also differences for Linux per distro, if differences exist (I'm not sure about that).

• expectations about symlinking versions, e.g. if it's expected on Linux that otio 1.1.5 is linked by a 1.1 symlink and that by a 1 symlink, that should be laid out as well, and accomplished within the Cmake script.

• mods as necessary to the Cmake config file installation.

Thanks

[darix]

For the question "when do we need to change the soversion" ... there are tools now and you do not have to do that manually anymore. Those can even be integrated into the testsuite or so.

• https://youtu.be/b1fO-RLtDME
• https://media.ccc.de/v/1234-libabigail-how-semantic-analysis-of-c-and-c-elf-binaries-can-be-used-to-analyze-abi-changes
• https://github.com/ansasaki/abimap

For when to bump which part of the whole soversion ... I am sure the semantic versioning for libraries explains that quite well.

[meshula]

Thanks for the pointers!

[JeanChristopheMorinPerso]

I think the SO versioning is kind of tracked in #872.

As for allowing the python extension to use the shared library, it's technically doable, with a patch or two. But it could be made easier than having to manually patch OTIO (though, the patches are simple).

[meshula]

Thanks for the link. Semantic versioning and SOVERSION are related, but not the same thing. i.e. some semantic version bumps need to bump SOVERSION, and SOVERSION can bump for reasons not related to a semantic version bump.

[JeanChristopheMorinPerso]

Ah ok, I wasn't sure. But I guess it's still good to have both linked in GH.