search

boostorg / gil

Boost.GIL - Generic Image Library | Requires C++14 since Boost 1.80
https://boostorg.github.io/gil
Boost Software License 1.0
178 stars 163 forks source link

fix: re-allow devicen_t with two color components #654

Closed striezel closed 2 years ago

striezel commented 2 years ago

Description

devicen_t<2> was possible in Boost 1.71, but broke in Boost 1.72. Now it's possible to use it again.

Since there was no real need to disallow it in the first place, I adjusted the static_assert which prevented it to allow two components, too.

References

Fixes #519.

See that issue for more information.

Tasklist

mloskot commented 2 years ago

Despite some jobs fail (w/ older clang and GCC 8 cxxstd=17) I'm happy to merge it. Thanks!

striezel commented 2 years ago

Thanks for merging it. :+1:

The jobs for GCC 8 and older Clang variants also failed before that, see e. g. here: https://github.com/boostorg/gil/actions/runs/2321824140 I don't know why the GCC 8 job fails, but in case of the Clang jobs it's just that there are no GitHub Actions runners with Ubuntu 16.04 anymore, and those older Clang jobs are still trying to use Ubuntu 16.04.

That's why I mentioned that those Clang jobs should possibly be removed in https://github.com/boostorg/gil/pull/640#issue-1194914999:

Note: Some older Clang versions (Clang 3.8 and older) seem to be unavailable in the APT package repository, so those are not changed to 18.04. This is intended. Maybe tests for Clang 3.4 to Clang 3.8 should be removed, but that is probably worth another discussion.

If removal of those jobs is not an option, then maybe someone should look into how to build with Clang 3.x on other, still available runners.

mloskot commented 2 years ago

I don't know why the GCC 8 job fails

We have seen similar failures where a particular compiler version with particular C+ version and build configuration variant generates segfaulting binary or it fails with internal compiler error. Either GIL stretches some compilers to the limits or there is a subtle bug that is hard to reproduce :-)

So, I don't mind disabling such peculiar CI jobs. We are not testing compilers after all.

UPDATE: Done in 4ad824e8dd379632809cf0b57478252b985fb5cf