On 10/08/2016 14:36, Pekka Paalanen wrote:
On Tue, 9 Aug 2016 11:05:49 +0300
Pekka Paalanen <[email protected]> wrote:
On Mon, 8 Aug 2016 15:59:37 +0200
Quentin Glidic <[email protected]> wrote:
On 08/08/2016 15:45, Pekka Paalanen wrote:
On Tue, 5 Jul 2016 20:41:50 +0200
Quentin Glidic <[email protected]> wrote:
From: Quentin Glidic <[email protected]>
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 <[email protected]>
---
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?
The issue shows up for this kind of protocol:
<request name="something" since="3" />
<event name="something" since="2" />
Currently, with this protocol, including both client and server headers
will fail, because one #define will be 3 and the other 2.
This patch will break even when including one header.
I guess this kind of protocol is just considered bad design? :-)
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.
Hi all,
after talking to my colleagues and noting that no Microsoft
compiler would ever be used to compile this code, my worries have
cleared.
GCC has this:
https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html
I assume Clang would be similar.
We can add duplicate #defines just fine. In the unlikely case that it
will blow up something, we can fix the generator to emit
#ifndef/#define/#endif instead of just #define.
How's that for a contingency plan?
Good enough for me.
The patch is
Reviewed-by: Pekka Paalanen <[email protected]>
Thanks,
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
