Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
wayland
wayland
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 94
    • Issues 94
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 24
    • Merge Requests 24
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • wayland
  • waylandwayland
  • Issues
  • #168

Closed
Open
Opened Jun 04, 2020 by wm4@wm4

Simultaneous requirement for code generation (wayland-scanner) and dynamic invocation (libffi) is unnecessarily roundabout, complicated, and problematic

Currently, it appears that using a wayland protocol requires code generation with wayland-scanner, and in addition internal dynamic dispatching with libffi. Why does it have to complex? In particular, while a wayland client doesn't have to care about the fact that libffi is apparently used internally, the code generation with wayland-scanner is roundabout and complicates the build system.

It's made even worse by wayland-scanner generation two parts (a header and a .c file). Also, you can't just include all the generated .c files in a single .c file (to simplify the build process), because there are completely unnecessary symbol collisions. And even much worse, the .c files are tiny, while the .h files contain significant amounts of code (like inline functions).

If libffi is already used, why require wayland-scanner? It feels like there could be a more streamlined concept for protocol support.

I suggest one of the following alternatives:

  1. Provide pre-built protocol libraries, like anyone else does it. (X11, Windows, Android, OSX, iOS, none require you to auto-generate code.)
  2. Use code-generation only. Make it simpler; generate only a .h file, or make the .h file minimal so compile time and binary code is minimized. Carefully consider impact on build systems.
  3. Use dynamic dispatch only.
Edited Aug 10, 2020 by Peter Hutterer
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: wayland/wayland#168