ports/xorg
3
0
Fork 0
Code Issues Pull Requests Activity

mesa-demos: disable wayland in order to satisfy wrap-mode nodownload #1

New Issue
Closed
opened 2023-04-01 13:59:38 +02:00 by farkuhar · 2 comments
farkuhar commented 2023-04-01 13:59:38 +02:00
Member
Copy Link

As reported by ppetrov^, if wayland is detected during setup, meson tries to download the libdecor subproject. But with "--wrap-mode nodownload", this operation fails.

According to the ChangeLog https://lists.freedesktop.org/archives/mesa-announce/2023-March/000711.html , the subproject wrapper was added in the 9.0.0 release because they decided to "use libdecor for top-level decoration" (Hoe Hao Cheng). If it's desired that our port of mesa-demos continues supporting wayland, there are three workarounds that come to mind:

  1. add a test for libdecor.so immediately after 'prt-get isinst wayland', and exit early with an informative error message if not found.

  2. add a README in the port directory telling the user to install libdecor if they have wayland.

  3. add a libdecor tarball in the source array, but only build it if wayland is found.

Option 3 requires the least amount of intervention by the user, but it violates the guideline against bundling distinct software packages within a single port, and it wastes bandwidth for users who don't have wayland. Option 1 will have the most unfamiliar behaviour, but anyone who's tried to build contrib/libreoffice without harfbuzz linked against icu (or xmlsec linked against nss) will recognize the message.

As reported by ppetrov^, if wayland is detected during setup, meson tries to download the libdecor subproject. But with "--wrap-mode nodownload", this operation fails. According to the ChangeLog https://lists.freedesktop.org/archives/mesa-announce/2023-March/000711.html , the subproject wrapper was added in the 9.0.0 release because they decided to "use libdecor for top-level decoration" (Hoe Hao Cheng). If it's desired that our port of mesa-demos continues supporting wayland, there are three workarounds that come to mind: 1. add a test for libdecor.so immediately after 'prt-get isinst wayland', and exit early with an informative error message if not found. 2. add a README in the port directory telling the user to install libdecor if they have wayland. 3. add a libdecor tarball in the source array, but only build it if wayland is found. Option 3 requires the least amount of intervention by the user, but it violates the guideline against bundling distinct software packages within a single port, and it wastes bandwidth for users who don't have wayland. Option 1 will have the most unfamiliar behaviour, but anyone who's tried to build contrib/libreoffice without harfbuzz linked against icu (or xmlsec linked against nss) will recognize the message.
farkuhar commented 2023-04-01 14:02:55 +02:00
Author
Member
Copy Link

If it's not deemed essential for our mesa-demos port to continue supporting wayland, there's the simple solution recommended in the title: just pass '-D wayland=disabled' to meson setup.

If it's not deemed essential for our mesa-demos port to continue supporting wayland, there's the simple solution recommended in the title: just pass '-D wayland=disabled' to meson setup.
tb commented 2023-04-05 20:35:55 +02:00
Owner
Copy Link

Feel free to tell me if 77532889 fixes the problem

Feel free to tell me if 77532889 fixes the problem
tb added the
bug
 label 2023-04-05 20:49:42 +02:00
tb self-assigned this 2023-04-05 21:12:26 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
No Label
bug
Milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees tb
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ports/xorg#1
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?