Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-73099

Stop using deprecated wayland-scanner argument "code" (Qt 6)

    XMLWordPrintable

Details

    • Task
    • Resolution: Done
    • Not Evaluated
    • 6.0
    • None
    • QPA: Wayland
    • None
    • Linux/Wayland

    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

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              tvete Paul Olav Tvete
              johanhelsing Johan Helsing
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes