[PATCH wayland 2/6] wayland-egl: make wayland-egl-backend.h C++ safe

[Emil Velikov]

On 16 February 2018 at 10:49, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Emil,
>
> On 16 February 2018 at 10:40, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 15 February 2018 at 23:12, Derek Foreman <derekf at osg.samsung.com> wrote:
>>> Maybe it's just me, but having different names for the same variable for C
>>> vs C++ compilation seems really nasty and potentially surprising.
>>>
>> Indeed it is surprising. In practise nobody should be using C++.
>> The guards are added just for lolz - but we can flip things the other
>> way around.
>> Namely, error out when using C++ ;-)
>
> I mean, effectively we did before the rename, by using a reserved keyword ...
>
Indeed.

>>> Shouldn't old versions of Mesa already have internal versions of this header
>>> anyway?  I didn't think it was publicly installed until now...
>>>
>> That's what Dan't patch did. Sadly as-is (before this series) every
>> Mesa release under the sun - released or git will fail to build.
>> I don't think we can retroactively go and fix the all :-(
>
> Every one? As far as I'm aware, it's only for 17.3.x. If we apply my
> patch to explicitly pick the path, then all 18.x will be fine (since
> they use an explicitly internal path), 17.2.x and below are all fine
> (since the file was still called wayland-egl-priv.h), and presumably
> 17.3.x will be seeing another stable release which could trivially fix
> that as well.
>
> OTOH, if we keep releasing Mesa with ambiguous includes of
> wayland-egl-backend.h, then we can't change API details inside that
> struct, for as long as we want to support these releases. Hence why
> I'd go with the patch to disambiguate the includes, or maybe renaming
> wayland-egl-backend.h in Mesa to wayland-egl-mesa-backend.h or
> something.
>
You're right - only 17.3.x and 18.0 will need fixing. The more I think
about it, the more I'm inclined towards your solution.
Consider 1/6 and 2/6 dropped.

Thanks
Emil