Details
-
Task
-
Resolution: Done
-
Not Evaluated
-
None
-
None
Description
When building Qt and also when building custom extensions, this is shown in the log output:
wayland-scanner --include-core-only code < /home/johan/dev/qt/dev/qtwayland/src/3rdparty/protocol/wayland.xml > wayland-wayland-protocol.c Using "code" is deprecated - use private-code or public-code. See the help page for details.
The "code" option is not documented in the wayland-scanner -h output. Looking at the patch (wayland commit 9b76def674) that introduces the new options though:
scanner: introduce "public-code" and "private-code" The options are used to indicate how the code will be used - will it be public, as part of a DSO or private. In nearly every instance, people want to use the latter. One noticeable exception is the wayland libraries. They provide the base marshalling protocol that everyone uses. The option "code" was deprecated in favour of "public-code" with a warning message produced to guide people.
At the time of writing, "code" is still doing the same thing as "public-code" (except printing the warning) in the latest wayland version. I doubt that it will go away soon, so one possibility is to just ignore this warning and them switch to public-code when we bump the minimum wayland requirement to 1.15.0 or newer.
It would, however, probably be a good idea to look into whether we would rather use private-code instead.
As far as I can tell, the difference between private/public is whether some parts of the generated API will be exported outside the QtWayland modules or not.
More specifically, it controls whether to use _attribute_ ((visibility("hidden"))) or _attribute_ ((visibility("default"))) on the interfaces. More info on that here: http://gcc.gnu.org/wiki/Visibility
The generated interfaces that will change visibility, is, for instance:
WL_EXPORT const struct wl_interface wl_surface_interface = { ····"wl_surface", 4, ····10, wl_surface_requests, ····2, wl_surface_events, };
Which is declared in the header wayland-wayland-server-protocol.h:
extern const struct wl_interface wl_surface_interface;
So what happens if someone tries to use these from outside the shared library (i.e. in plugins or application code)? In case it breaks something can we hide them more completely? At the moment they are installed as private headers as well as being included indirectly by the qtwaylandscanner wrapper classes (also private), i.e. in qwayland-server-wayland.h:
#include <QtWaylandCompositor/private/wayland-wayland-server-protocol.h>
Attachments
Issue Links
- depends on
-
QTBUG-73636 Bump libwayland requirement to 1.15.0 or newer
- Closed
- is required for
-
QTBUG-68847 Qt Wayland Changes planned for Qt 6
- Closed