[OCIO-V2] OCIO_LIBNAME_SUFFIX not applied to Python library

[sobotka]

Summary says it all. It appears the cmake OCIO_LIBNAME_SUFFIX is correctly applied to the standard binary, but not the Python library.

Current as of 22a5f55548747265e55a6cc4e3b129b1e9fb8ec8

[hodoulp]

Good catch @sobotka

After some investigations (on macOs with gcc) here are my findings:

• Using -DOCIO_LIBNAME_SUFFIX=Autodesk, the core library name is changed, the namespace is not and all static library names are not. As found by you, the Python library (i.e. the Python bindings) name is not changed.
• Using -DSOVERSION=Autodesk, nothing changed!

Here are some thinkings / questions:

• Concerning the Python binding library name, I do not know what is the guideline when two Python 'modules' with diff. versions are supposed to run side-by-side. Any hints / suggestions ?

Perhaps that's not up to the OCIO project to manage the module / packages versions. The Python virtual environment does it as suggested by @remia.

• Concerning the suffix name and soversion, the two are confusing. If dev changes the name of the library it could mean that he wants to have a dedicated OCIO library (i.e. the library plus some private patches or two OCIO libraries running side-by-side) then I would expect the library name be changed but also the namespace. Otherwise, the integration could face some symbol conflicts. As it is today, the use case of two different libraries (one proprietary and one generic) running side-by-side could fail at compile time or at runtime depending of the differences between the two public APIs. Any ideas / suggestions ?

Note: The SOVERSION support is not clear on the Windows platform i.e. the documentation highlights a support but all my experiments failed. Anyone with some experience?

A suggestion is to have a dedicated define (for example -DOCIO_CUSTOM_LIBRARY=MyProduct and remove OCIO_LIBNAME_SUFFIX & SOVERSION supports) which changes all the library and the namespace names so it's consistent and clearly a custom library.

[sobotka]

If dev changes the name of the library it could mean that he wants to have a dedicated OCIO library (i.e. the library plus some private patches or two OCIO libraries running side-by-side) then I would expect the library name be changed but also the namespace.

Is there a clean way to solve the most “common” case for V2 vs V1 integration / development? This would strike me as the oncoming freight train as various pipelines try to integrate V2 into their pipe, including development of DCC software.

That is, without drilling too far into the namespace issue, is there a clean path to concurrently support both libraries simultaneously, assuming the code uses the correct namespace firewalling?

This is sort of the issue that I am bumping into with trying to keep a clean V2 Python library working for developing OCIO tutorials, without exploding my system and all of the cross linked software needing V1.

[luanbach-fn]

Has this been addressed? PyOpenColorIO.so is still not following the OCIO_LIBNAME_SUFFIX setting.