legacy-support and Wayland

Chris Jones jonesc at hep.phy.cam.ac.uk
Tue Oct 15 08:40:02 UTC 2019


Hi,

On 15/10/2019 9:20 am, René J. V. Bertin wrote:
> Chris Jones wrote:
> 
> Sorry, missed your reply.
> 
> I guess what I'm asking is: the legacy-support package/project must have come
> into existence because of an interest in running code that requires functions
> not present in all Mac OS versions - does that interest cover Wayland too?

I am not disputing the idea that adding support for Wayland to MacPorts 
would be a good idea. It would be. Just that legacy-support is not the 
place to add it. It is there to add as required to older OSes low level, 
small, system library methods added in newer OSes. e.g. clock_gettime 
that only exists in 10.12+. It is not the place to add an entirely new 
feature set such as Wayland, to all OSes (no macOS release has wayland 
support). Wayland support should be added in its own dedicated set of 
ports, not shoe horned into one it has no place being in.

cheers Chris

> 
> I think that at some point we'll start seeing Wayland-only versions of
> applications from the Gnome universe.
> 
> R.
>>
>> Not really sure what you are asking. legacy-support package is blind to
>> what ports might be using it. It just supplies functionality missing on
>> older OSes. If some hypothetical future wayland port needs these
>> functions, it presumably could use the PG in the same way as everything
>> else does.
>>
>> Chris
>>
>> On 27/09/2019 9:32 am, René J.V. Bertin wrote:
>>> Hi,
>>>
>>> A quick question to the legacy-support devs: do you have any interest in
>>> whether or not these support functions (plus whatever else is needed and
>>> doable) could help building Wayland for Mac?
>>>
>>> FWIW, I brought up the idea of running Wayland with Jeremy H. back when he
>>> was still maintaining XQuartz, and he was very positive about the idea
>>> (including how it could improve X11 support - there's some sort of X11 server
>>> "backend" for Wayland).
>>>
>>> Proper Wayland support on Mac should also provide a more modern (and better
>>> integrated) platform for traditional Unix apps, possibly even for KDE/KF5 as
>>> an eco-system without need for patching Qt.
>>>
>>> R.
>>>
> 
> 


More information about the macports-dev mailing list