Fix #867: Support libavif 1.0 in CMake build #946
Conversation
libavif applies the `SameMajorVersion` policy, so libavif 1.x.y is not considered to be compatible with 0.x.y. To still be able to require at least libavif 0.8.2, we first look for any libavif 1.x.y, and only if that could not be found, we apply the old `find_package()` command.
|
This passes configure in the Ubuntu CI, which was broken due to updating to libavif 1.0.4, what happened because we're now running on Ubuntu 24.04 instead of Ubuntu 22.04. The failing tests are likely caused by updateing of other packages; I'll look into that as soon as possible. @vapier, I think it makes some sense to have rolling CI (i.e. to use ubuntu-latest instead of ubuntu-22.04 or whatever), but it likely would make sense to have a scheduled nightly run, so such issues can be noticed even if there are no commits for a while. I was quite surprised by the sudden CI failure. |
|
Note that I've checked this locally on Debian Bookworm, where I have libavif 0.11.1. It might make sense to additionally run on older Ubuntu (22.04 or even 20.04) to check that everything works with older libavif and other libraries. Note also that neither our Windows nor MinGW builds are actually configured with The test failures are likely due to #900, and and freetype/libraqm update (apparently not so minor rendering differences) (that might be #814). PS: libraqm0_0.7.0-4ubuntu1 vs libraqm0_0.10.1-1build1 |
libavif applies the
SameMajorVersionpolicy, so libavif 1.x.y is not considered to be compatible with 0.x.y. To still be able to require at least libavif 0.8.2, we first look for any libavif 1.x.y, and only if that could not be found, we apply the oldfind_package()command.