[openimageio] Bump to 2.1.11.2

[theblackunknown]

This pull requests bump OpenImageIO port version to 2.1.10

• What does your PR fix? N/A

• Which triplets are supported/not supported? Have you updated the CI baseline?
  I have tested a custom triplet x64-windows-static-release, but I am waiting on CI to iterate and validate others
  I haven't touched the CI baseline

• Does your PR follow the maintainer guide?
  Yes

[NancyLi1013]

Hi @theblackunknown thanks for this PR.
Could you update the requested changes?

[theblackunknown]

Now that I am aware of #8543 from @JackBoosY I would suggest to put this one on hold
I'll rebase mine on top of Jack's one once merged

[Pixel-Minions]

Good morning, version 2.1.11 released. I was having issues using this latest version with the port. It seems the way the patches have to be applied have changed from 2.1.10 to 2.1.11.

[theblackunknown]

Hi @huargovfx , I consider this PR on hold for now
The idea is to rebase my changes - and ideally upgrade to latest OpenImageIO - once #8543 is merged

If possible I would suggest to use this other PR is you don't need the latest OpenImageIO, otherwise please be a bit more patient :)

[JackBoosY]

@theblackunknown My PR #8543 has been merged, you can continue your work now : )

[theblackunknown]

Thanks ! Will do once I rebase my work !

[NancyLi1013]

/azp run

[JackBoosY]

Need to test features.

[NancyLi1013]

Hi @theblackunknown

Sorry for the late reply.

All features except for field3d(doesn't support Windows) passed with the following triplets:

• x86-windows
• x64-windows
• x64-windows-static

All features except for(libraw, pybind11) passed with x64-linux triplet.

Could you please help confirm and check the results about libraw and pybind11 on Linux?

[theblackunknown]

Hey @NancyLi1013 , I have just tested those features on a Linux OS
I have not encountered any trouble for libraw, however I did for pybind11.

In my opinion, the main issue is how pybind11 port manage its dependencies :

• On Windows, it relies on python3 from vcpkg port : this provide a consisten, controlled and reproducable behavior
• On other OSes, it relies on whatever system python is present : this is very inconsistent, and error prone when trying to have reproducable builds on different installations

Now, even if I found the correct package to install to make it work on Linux, I had to further tweak the portfile to make sure openimageio will use the python shared library and not the static one because otherwise the port will fail (because the former is compiled with -fPIC which is what openimageio python bindings requires)

So my last commit is hacky but make it pass for me,
I would suggest to fix the following ports :

• python3 by building shared library (currently tackled in [pybind11] Modernize port + better python dependency handling #9979)
• pybind11 by always relying on the upgraded python3 to get consistent and reproducable builds over any installations

What do you think ?
Whether we put this PR in draft/hold, or accept/reject the hack is up to you

[JackBoosY]

@theblackunknown
I think we must guarantee to use the built-in tools (git, python ...) of vcpkg to ensure that the actual effect in each triplet is consistent. And update these tools to make changes in all triplets at the same time.

[theblackunknown]

@JackBoosY
Just to be sure to understand, in the current case what are you suggesting to fix the issue ?
Make pybind11 relies on vcpkg port ? vcpkg downloaded python ? or something else ?

[JackBoosY]

@theblackunknown

• If OIIO depends on pybind, use vcpkg port pybind11 (Add Build-Depends: pybind11 to CONTROL)
• If OIIO use python3, use vcpkg installed tools python3(Use vcpkg_find_acquire_program)

[theblackunknown]

Ok, we agree on this and this is what the current port is currently doing

However the pybind11 port needs an upgrade because the wrong python libraries gets picked up in its current state :

• pybind11 relies on system python instead of vcpkg python
• we need to have python with shared library

I am currently tackling this issue in #9979

[NancyLi1013]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[theblackunknown]

@NancyLi1013 @JackBoosY same as my other PR, this one is also on hold as it requires the ones that are now closed
I am closing it for now until I go back to it