[PATCH wayland] introduce new headers wayland-client/server-core.h
giuliocamuffo at gmail.com
Wed Apr 29 09:18:55 PDT 2015
2015-04-29 19:06 GMT+03:00 Bill Spitzak <spitzak at gmail.com>:
> On 04/29/2015 12:21 AM, Giulio Camuffo wrote:
>> 2015-04-29 2:17 GMT+03:00 Bill Spitzak <spitzak at gmail.com>:
>>>>>>>> The problem is when you have an extension.xml, and generate
>>>>>>>> extension-client-protocol.h. Then you have some preexisting code
>>>>>>>> including that and relying on it including wayland-client.h and then
>>>>>>>> wayland-client-protocol.h, and if you use something from that it
>>>>>>>> not build anymore, because wayland-client-core.h doesn't include it.
>>> I think it is acceptable to say that the code has to be fixed in this
>>> It will only happen if they call a function that wayland-client.h defines
>>> but is not in wayland-client-core.h. You are being much too concerned
>>> back compatibility here.
>> No, i completely disagree. Weston wouldn't build, like probably
>> virtually any other project using some extension. That is not
> I just tested commenting out the "#include "wayland-client.h" from
> wayland-client-protocol.h and both wayland and weston built with no error.
> And that change is far more drastic than what I propose as it does not
> include the stuff that would be in this wayland-client-core.h file.
You commented it out from the wrong file. Comment it in iirc
desktop-shell-client-protocol.h instead, or some other file generated
from a protocol in weston.
> It is pretty easy to see using git grep that most (and perhaps all) files
> that include a protocol.h also directly include wayland-client.h. Some of
> them are indirectly through the window.h.
Most may very well work fine, but most is not all and we cannot break
existing code, period. We have an API stability promise to maintain.
>> Just to be clear, are you suggesting the scanner should generate two
>> headers for an xml, one including the old headers and one including
>> the core ones? I'm not sure i see the advantage of this compared to
>> the option...
> The back-compatibility one would be hand-written, not generated. It is only
> needed for existing protocols. However I don't feel this is necessary.
> Just to be clear, my proposal is:
> wayland-client.h : hand-written, includes:
> deprecated api
> wayland-client-core.h : hand-written, includes
> wl_event_queue, wl_proxy, etc
> *-protocol.h : generated, includes
> inline wrappers for messages and events
More information about the wayland-devel