deps: Add build recipe for PNG #4423
Conversation
Signed-off-by: Zach Lewis <[email protected]>
Required for building redistributable python wheels on Windows Wheels runners. Signed-off-by: Zach Lewis <[email protected]>
…dation#4429) This test was running very slowly, taking too long in all circumstances, but shockly causing GHA CI Mac runners to hit the test timeout sometimes. It turns out we were doing a lot of redundant work. There was no need to make separate pattern and bayer images for every data type. Instead, hoist the test image generation out of the loop and just make one (float), then use `-i:type=<type>` to read it into an ImageBuf of the appropriate data type. This cuts the time for this test to run by about 3x. Signed-off-by: Larry Gritz <[email protected]>
MacOS builds require that PNG_FRAMEWORK=OFF in order to find and install dynamic libraries... ...but Windows still has trouble finding and installing dynamic libraries. Only building static libraries seems to work, as far as building wheels is concerned; but I fear older dynamic libpngs found on the system will be preferred over newer static libpngs freshly-built by OIIO when linking. Signed-off-by: Zach Lewis <[email protected]>
|
Looks like we're still failing CI here |
|
indeed... it's the strangest thing. Still trying to get to the bottom of this. I think what's happening is, for systems that have a "too old" version of dynamic PNG libraries installed, now that there's a build recipe available, even if we build newer static PNG libs, the build system is still preferring to link the older shared libraries (even though they're too old). I dunno if this is a clue or a red herring, but it seems the build system might be getting confused about which version of PNG it's found versus the version it's trying to build (at least nominally): so... in the second line in the above log snippet, it claims to be "Building package PNG 1.5.13 locally", even though it's building 1.6.44. I'm not sure what, if anything, that has to do with the more serious problems:
A lesser problem, but one worth figuring out -- currently, I'm forcing the recipe to only build static libraries, cuz Windows has trouble figuring out what to do with / how to install the dynamic PNG library it just built. (I was having similar trouble on macOS until I set Ideally, we'd only link the static libraries, since that seems to behave properly across platforms, given the opportunity... |
|
I'm kind of baffled by the CI build failures... I can't seem to pinpoint anything in the logs or the configs that would explain why or how the failures occur on some runs, but not others... The problematic runs are:
And they all fail the same way: But... considering the rest of the checks pass, it doesn't seem to be an issue with the compiler or compiler version, the VFX202X build image, the version of Python, the version of EXR, the version of OCIO, or whether sse instructions are used. And I can't seem to ascertain a particular constellation of settings that produces a failure. The only thing I could identify that looked suspicious to me is the ordering of paths in the The logs aren't verbose enough for successful builds for me to tell if this is the difference that explains the failures of unsuccessful runs. |
Attempt to force the build system to always find the locally-built PNG before any system-installed PNGs Signed-off-by: Zach Lewis <[email protected]>
Signed-off-by: Zach Lewis <[email protected]>
zachlewis
force-pushed
the
build_PNG
branch
from
745c6e0
to
aa2565d
Compare
*Now* it should use PNG's CMake Config.... Signed-off-by: Zach Lewis <[email protected]>
Signed-off-by: Zach Lewis <[email protected]>
Signed-off-by: Zach Lewis <[email protected]>
Signed-off-by: Zach Lewis <[email protected]>
As requested in #4387.