[RFC] Declare enumeration wl_output.transform as bitfield.

[Daniel Stone]

Hi,

On 25 November 2015 at 14:17, Auke Booij <auke at tulcod.com> wrote:
> On 25 November 2015 at 13:43, Daniel Stone <daniel at fooishbar.org> wrote:
>> Warnings aren't harmless though; there's a reason we don't (shouldn't)
>> have any in our build. Every 'oh, just ignore that' warning drowns out
>> legitimate compiler warnings, and dumping warnings on our users
>> because we broke a stable API isn't really acceptable. So, sorry, but
>> NAK from me. :(
>
> Note that this these warnings are resolvable: e.g. the weston code can
> be fixed so that it does not generate warnings under this change.
> (Although I understand that that is not quite sufficient.)

Sure, we can fix Weston, and with a strict version requirement on the
protocol, we can make sure it doesn't come back. But what about
XWayland, Mesa, GTK+, Qt/KDE, Clutter/Cogl/Mutter, GStreamer,
Ozone/Chromium, Firefox, LibreOffice, and all the others?

> Under what conditions would you agree to this protocol change? E.g.
> would more documentation towards developers regarding the warnings
> help? Or some sneaky way to avoid compiler warnings?

I can't really think of a sneaky way, in all honesty: we're changing a
prototype. Even some clever #define / #ifdef dance to opt in to the
new behaviour doesn't help, because a protocol header may well be
included before the #define gets set. When you consider mixing and
matching various modules, some of which are aware of the new type
signature, some of which aren't, there's basically no way to do it
cleanly.

Unfortunately I can't really think of a situation where I would find
it palatable. It is a good and correct change on the face of it, but
unfortunately we've already encoded this bad API, and changing it will
infuriate everyone using it downstream. I'd say just accepting that we
can't make it a bitfield because legacy, and encoding all possible
combinations for languages which won't let you do arbitrary binary
operations, would be a less-bad solution.

Cheers,
Daniel