[PATCH wayland 2/2] scanner: Generate all SINCE_VERSION macros for everyone

Pekka Paalanen ppaalanen at gmail.com
Tue Aug 9 08:05:49 UTC 2016


On Mon, 8 Aug 2016 15:59:37 +0200
Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:

> On 08/08/2016 15:45, Pekka Paalanen wrote:
> > On Tue,  5 Jul 2016 20:41:50 +0200
> > Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:
> >  
> >> From: Quentin Glidic <sardemff7+git at sardemff7.net>
> >>
> >> Practical example: a client supporting version 2 of wl_output will wait
> >> for the wl_output.done event before starting wl_output-related
> >> operations. However, if the server only supports version 1, no event
> >> will ever come, and it must fallback to use the wl_output.geometry event
> >> alone.
> >> Without this macro, it cannot check for that in a nice way.
> >>
> >> Signed-off-by: Quentin Glidic <sardemff7+git at sardemff7.net>
> >> ---
> >>
> >> I do not have a real world use-case for the request macro on the server-side,
> >> but I guess you could do the same: wait the for a "commit" request if client is
> >> new enough, otherwise use some older request as commit.
> >>
> >> Actually I think there was something like that somewhere, now that I write that,
> >> but I do not remember where exactly.
> >>
> >>
> >>  src/scanner.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/src/scanner.c b/src/scanner.c
> >> index 4708cae..a4c1984 100644
> >> --- a/src/scanner.c
> >> +++ b/src/scanner.c
> >> @@ -1544,10 +1544,12 @@ emit_header(struct protocol *protocol, enum side side)
> >>  			emit_structs(&i->request_list, i, side);
> >>  			emit_opcodes(&i->event_list, i);
> >>  			emit_opcode_versions(&i->event_list, i);
> >> +			emit_opcode_versions(&i->request_list, i);
> >>  			emit_event_wrappers(&i->event_list, i);
> >>  		} else {
> >>  			emit_structs(&i->event_list, i, side);
> >>  			emit_opcodes(&i->request_list, i);
> >> +			emit_opcode_versions(&i->event_list, i);
> >>  			emit_opcode_versions(&i->request_list, i);
> >>  			emit_stubs(&i->request_list, i);
> >>  		}  
> >
> > Hi,
> >
> > I have just one question about this. Users must be able to include both
> > server and client headers in the same compilation unit. Wouldn't this
> > cause the same thing to be #defined in two different headers? More
> > importantly, are we sure it won't cause problems?  
> 
> At least with GCC, you can have twice the same #define (same name + same 
> value) without issue. I do not know about the C standard take on that 
> though.

Hi,

I would need more proof/opinions than just a "it worked for me".

> If that would cause problems, it would be because a request and an event 
> have the same name, and come from different versions. But if a user must 
> be able to include both client and server headers, it is already an issue.

I think we can assume that client and server side should use the same
version of the XML files.

How is it already an issue? Do we already #define something in both
headers?

At least we already seem to have a test in the Wayland test suite that
includes both client and server protocol headers in the same
compilation unit.

> If you really want, I can make server-side define events + prefixed 
> requests and the other way around.
> 
> server.h:
> #define NAMESPACE_INTERFACE_SOMEEV_SINCE_VERSION 2
> #define NAMESPACE_INTERFACE_REQUEST_SOMEREQ_SINCE_VERSION 3
> client.h:
> #define NAMESPACE_INTERFACE_EVENT_SOMEEV_SINCE_VERSION 2
> #define NAMESPACE_INTERFACE_SOMEREQ_SINCE_VERSION 3

I'd like to avoid that naming hassle if possible. I just want to know
if it is possible.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160809/37abca25/attachment.sig>


More information about the wayland-devel mailing list