[PATCH wayland] introduce new headers wayland-client/server-core.h

[Bill Spitzak]

On 04/30/2015 11:03 AM, Giulio Camuffo wrote:

> Functionally the initial patch and the latest ones are exactly the
> same, so not sure what you're talking about....

No they are not. The original patch and my proposal has 
*-client-protocol.h file including wayland-client-core.h. The latest one 
has it including wayland-client.h.

My proposal is to make --include-core-only true always. This I think was 
the original proposal as well. They are obviously different than the 
current proposal because otherwise there would not be any need for the 
switch.

>> I am trying to remove the circular dependency in the current headers and in
>> the "!include_core_only" default case for wayland-scanner. It would also be
>> nice to not force programs using a protocol to include a now-deprecated
>> header!
>
> What circular dependency? And who forces anybody? They can use
> --include-core-only and never ever include wayland-client.h.

The distributed header files with wayland are produced without the 
--include-core-only switch and therefore have a circular dependency:

   wayland-client-protocol.h <-> wayland-client.h

Most users of wayland are not generating protocol header files, and 
certainly have no reason to do it for the core protocol.

>> If back compatibility is really a concern, a better fix would be this:
>>
>>    wayland-client.h : deprecated, hand-written
>>      wayland-client-core.h
>>      wayland-protocol-client.h
>>      deprecated api
>>
>>    wayland-client-core.h : hand-written, matches existing proposal
>>
>>    *-protocol-client.h : generated by wayland-scanner
>>      wayland-client-core.h
>>      wrappers for messages/events/proxy
>>
>>    *-client-protocol.h : very short file generated by wayland-scanner
>>      comment that this file is deprecated
>>      *-protocol-client.h
>>      wayland-client.h
>>
>> IMHO back-compatibility is NOT a problem. I posted a patch for weston and it
>> was 2 lines.
>
> So what you are suggesting basically is on top of the current patches
> to have the wayland build generate also protocol headers with
> --include-core-only and to install them. I am not sure i see the
> benefit of this, since whoever includes the pre-generated protocol
> headers is evidently including them, and the sole reason of this
> patchset was to be able to *not* include them.

I am not proposing the same as running wayland-scanner twice. What I am 
proposing is that wayland-scanner always act like --include-core-only is 
true, but it writes a *new* file (I swapped the words "protocol" and 
"client" to get the new name). There is also a TINY file using the old 
name that includes both the new one and wayland-client.h.

I agree this is ugly and that is why I think the change that would break 
a few existing pieces of code is better. But I think this is the only 
acceptable solution, as the circular dependency in the distributed 
headers has to be removed.