Need some advice regarding patches for old AppKit compatibility

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Need some advice regarding patches for old AppKit compatibility

Jason Liu
In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu
Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Christopher Jones
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu


smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Jason Liu
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu

Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Jason Liu
Looking through the link that Chris provided, it looks like the MacPorts legacy support package might indeed be the perfect place to add my AppKit compatibility layer file. One tiny question that I have is: In the readme, where it says "GNU make is a hard build dependency", does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 5:34 PM Jason Liu <[hidden email]> wrote:
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu

Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Ken Cunningham
In reply to this post by Jason Liu
does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

That line, and a lot of the other stuff added recently to the front page, is quite confusing. I plan to strip all that out soon. It's not helpful for users.

No special requirements are needed. Just ignore that. one line in the portfile, and legacysupport is all taken care of...you don't need to do anything more by default.

I'm not sure what kind of effect having your list of redefines automatically added might have...or which header it would override, exactly...but looks handy, if it helps!

Ken

Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Christopher Jones
In reply to this post by Jason Liu


On 4 Jun 2020, at 5:50 am, Jason Liu <[hidden email]> wrote:

Looking through the link that Chris provided, it looks like the MacPorts legacy support package might indeed be the perfect place to add my AppKit compatibility layer file. One tiny question that I have is: In the readme, where it says "GNU make is a hard build dependency", does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

Just the former. ports using it can use other build systems. it works well with most build systems, but not all. which do you have in mind ?

Chris


Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 5:34 PM Jason Liu <[hidden email]> wrote:
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu



smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Jason Liu
Well, Blender and MaterialX both use cmake to build, so hopefully it'll work without any major issues.

Then, my next question is: If the header that I'm going to be wrapping is #include <AppKit/AppKit.h>, then where should I be putting my file in the macports-legacy-support package? I'm assuming inside the include/ folder, but then what? Do I need to create an AppKit/ subfolder inside there?

Actually, the reality is a bit more complicated than that. The source codes of Blender and MaterialX actually use #include <Cocoa/Cocoa.h>, which if you take a look at the file located at /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h, has #import <AppKit/AppKit.h>. Hopefully just wrapping AppKit.h will be sufficient?

Jason

-- 
Jason Liu


On Thu, Jun 4, 2020 at 5:49 AM Christopher Jones <[hidden email]> wrote:


On 4 Jun 2020, at 5:50 am, Jason Liu <[hidden email]> wrote:

Looking through the link that Chris provided, it looks like the MacPorts legacy support package might indeed be the perfect place to add my AppKit compatibility layer file. One tiny question that I have is: In the readme, where it says "GNU make is a hard build dependency", does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

Just the former. ports using it can use other build systems. it works well with most build systems, but not all. which do you have in mind ?

Chris


Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 5:34 PM Jason Liu <[hidden email]> wrote:
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu


Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Christopher Jones
Hi,

On 4 Jun 2020, at 3:06 pm, Jason Liu <[hidden email]> wrote:

Well, Blender and MaterialX both use cmake to build, so hopefully it'll work without any major issues.

Then, my next question is: If the header that I'm going to be wrapping is #include <AppKit/AppKit.h>, then where should I be putting my file in the macports-legacy-support package? I'm assuming inside the include/ folder, but then what? Do I need to create an AppKit/ subfolder inside there?

yes, under the include/ dir. you need to replicate the same structure as would normally be included, so if that is

<AppKit/AppKit.h>

then you need to replicate exactly that.

Then, inside that file there are certain things you need to do.  check some of the other examples. but it boils down to

1. use 

#include_next <AppKit/AppKit.h>

that triggers the inclusion of the header that would have been used, if the wrapper did not exist. Doing this makes builds blind to the fact they are using the wrapper.

2. Inside appropriate OSX version checks, add the additional bits and pieces you need to add to support older OSX versions. The checks should be specific to make sure its only done when needed. See 

MacportsLegacySupport.h

for how this is done.

If all you need to do is add a few typedefs to deal with some type renaming, then what you need to add insider the OS check is quite simple (i.e. doesn’t need an associated X.c file).

3. Finally, we really like to have basic tests to validate the new features. Whatever you think makes minimal sense. see the test dir for examples.

Chris




Actually, the reality is a bit more complicated than that. The source codes of Blender and MaterialX actually use #include <Cocoa/Cocoa.h>, which if you take a look at the file located at /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h, has #import <AppKit/AppKit.h>. Hopefully just wrapping AppKit.h will be sufficient?

Jason

-- 
Jason Liu


On Thu, Jun 4, 2020 at 5:49 AM Christopher Jones <[hidden email]> wrote:


On 4 Jun 2020, at 5:50 am, Jason Liu <[hidden email]> wrote:

Looking through the link that Chris provided, it looks like the MacPorts legacy support package might indeed be the perfect place to add my AppKit compatibility layer file. One tiny question that I have is: In the readme, where it says "GNU make is a hard build dependency", does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

Just the former. ports using it can use other build systems. it works well with most build systems, but not all. which do you have in mind ?

Chris


Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 5:34 PM Jason Liu <[hidden email]> wrote:
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu




smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need some advice regarding patches for old AppKit compatibility

Jason Liu
Ok, that all sounds logical. I'll work on putting together the code, and then I'll report back to everyone here on the mailing list before I start actually trying to add anything to the tree. I'll probably end up with some additional questions along the way.

Jason

-- 
Jason Liu


On Thu, Jun 4, 2020 at 4:10 PM Christopher Jones <[hidden email]> wrote:
Hi,

On 4 Jun 2020, at 3:06 pm, Jason Liu <[hidden email]> wrote:

Well, Blender and MaterialX both use cmake to build, so hopefully it'll work without any major issues.

Then, my next question is: If the header that I'm going to be wrapping is #include <AppKit/AppKit.h>, then where should I be putting my file in the macports-legacy-support package? I'm assuming inside the include/ folder, but then what? Do I need to create an AppKit/ subfolder inside there?

yes, under the include/ dir. you need to replicate the same structure as would normally be included, so if that is

<AppKit/AppKit.h>

then you need to replicate exactly that.

Then, inside that file there are certain things you need to do.  check some of the other examples. but it boils down to

1. use 

#include_next <AppKit/AppKit.h>

that triggers the inclusion of the header that would have been used, if the wrapper did not exist. Doing this makes builds blind to the fact they are using the wrapper.

2. Inside appropriate OSX version checks, add the additional bits and pieces you need to add to support older OSX versions. The checks should be specific to make sure its only done when needed. See 

MacportsLegacySupport.h

for how this is done.

If all you need to do is add a few typedefs to deal with some type renaming, then what you need to add insider the OS check is quite simple (i.e. doesn’t need an associated X.c file).

3. Finally, we really like to have basic tests to validate the new features. Whatever you think makes minimal sense. see the test dir for examples.

Chris




Actually, the reality is a bit more complicated than that. The source codes of Blender and MaterialX actually use #include <Cocoa/Cocoa.h>, which if you take a look at the file located at /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h, has #import <AppKit/AppKit.h>. Hopefully just wrapping AppKit.h will be sufficient?

Jason

-- 
Jason Liu


On Thu, Jun 4, 2020 at 5:49 AM Christopher Jones <[hidden email]> wrote:


On 4 Jun 2020, at 5:50 am, Jason Liu <[hidden email]> wrote:

Looking through the link that Chris provided, it looks like the MacPorts legacy support package might indeed be the perfect place to add my AppKit compatibility layer file. One tiny question that I have is: In the readme, where it says "GNU make is a hard build dependency", does that sentence mean that the MacPorts legacy support package itself needs GNU make, or does it mean that any portfile that uses the legacysupport PortGroup needs to add GNU make as a build dependency?

Just the former. ports using it can use other build systems. it works well with most build systems, but not all. which do you have in mind ?

Chris


Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 5:34 PM Jason Liu <[hidden email]> wrote:
Great, I'll have a look at the stuff in that area. Thanks, Chris.

Jason

-- 
Jason Liu


On Wed, Jun 3, 2020 at 2:38 PM Christopher Jones <[hidden email]> wrote:
Hi,

Sounds like this *could* be a candidate for something to add to our legacy support package. see


A port for this exists in MacPorts, and is applied as required to ports that need the support layer using the legacysupport PortGroup.

I think if we are to have a compatibility layer, as you describe below, putting it in the same place as the above is the way to go, so please take a look and submit MRs adding what you think is needed to it.

Chris

On 3 Jun 2020, at 7:01 pm, Jason Liu <[hidden email]> wrote:

In my course of packaging some new ports, I've run across a couple instances of applications which are claimed by their devs to only be compatible with "macOS 10.12 and above". However, I've discovered that in reality, the only reason they're no longer compatible with older versions of macOS is because the names of a lot of constants changed in AppKit starting in 10.12. All of these constants appear to be related to either the drawing of GUI Cocoa windows or UI events (e.g. mouse down, mouse dragged, etc.).

So far, I've encountered two pieces of software where this is happening: Blender and MaterialX.

A solution I found which some projects (e.g. Qemu) have implemented basically replaces the new AppKit constants with the old AppKit ones using #define directives if the OS version is below 10.12. I've created a separate header file that gathers together a list of the constants I've been able to find, which is modeled on information from this message:


I'm doing my portfile development on a machine running 10.11, and have verified that my patch seems to allow me to build these applications without any noticeable issues (no runtime crashes, segfaults, etc.).

So my question to everyone is: Should I just add my header file to the files/ folder for whichever ports need it? Or is this something that might benefit from me creating a project in GitHub? I'm guessing that there could be other software packages which might benefit from such a compatibility layer.

-- 
Jason Liu