[Piglit] [PATCH] egl-util: Define EGL_KHR_gl_colorspace symbols for older distros.y

[Emil Velikov]

On 10 July 2015 at 19:14, Dylan Baker <baker.dylan.c at gmail.com> wrote:
> On Fri, Jul 10, 2015 at 10:36:09AM +0100, Emil Velikov wrote:
>> On 10 July 2015 at 09:22, Dylan Baker <baker.dylan.c at gmail.com> wrote:
>> > Maybe a better plan is to have the test detect that those aren't defined and
>> > skip?
>> >
>
> Please explain why a test checking for required functionality and
> skipping if that functionality isn't present is not a valid solution?
I never said that. I said "maybe" - maybe it is, maybe it's not :-)

> This is AFAICT the way the piglit generally works, a test asks GL if the
> feature it tests are present, and skips if they are not.
>
> So in that case something as simple as:
> #ifndef <MY_CONSTANT>
> return PIGLIT_SKIP;
> #endif
>
> at the top of the main function should be sufficient.
>
There is a serious catch here - build time != runtime. Sometimes we
use separate machines, sometimes the package versions ("mesa-dev" vs
"mesa") are out of sync. Not to mention that the binary drivers don't
provide headers, so the (likely mesa provided) headers do not reflect
driver capability.
Perhaps it'll work on your setup, but it will likely cause issues elsewhere.

>> A few other suggestions:
>>  - Check that the headers are new enough and bail out early in cmake.
>> Unfortunately distros may insist on keeping old headers, despite that
>> updating (and using) them won't cause ABI breakage.
>
> This would make it impossible to build new piglit against a sufficiently
> old version of mesa (or any GL driver) (which could mean a year, or an
> hour), which would make bisecting regressions impossible.
>
It was kind of implied in the "silly distros, why you ship old stuff ?" rant.

>>  - Have a local copy of the headers in-tree.
>> Could get ugly, but many projects seems to be doing it.
>
> This also seems less than desirable, because now we're maintaining two
> copies, which will be error prone.
>
That's why I've mentioned that it could get ugly.

>> I'm leaning towards the former, although feel free to use whichever you fancy.
>>
All in all, I saw a (no offence) strange suggestion, so I decided to
throw a few wild/silly ideas. Vinson's approach is the one we want in
99.9% of the time. But as said before choose whatever you fancy - I'm
using git for most components of the graphics stack :)

-Emil