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 <jonesc at hep.phy.cam.ac.uk>
wrote:

>
>
> On 4 Jun 2020, at 5:50 am, Jason Liu <jasonliu at umich.edu> 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 <jasonliu at umich.edu> 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 <
>> jonesc at hep.phy.cam.ac.uk> wrote:
>>
>>> Hi,
>>>
>>> Sounds like this *could* be a candidate for something to add to our
>>> legacy support package. see
>>>
>>> https://github.com/macports/macports-legacy-support
>>>
>>> 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 <jasonliu at umich.edu> 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:
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04330.html
>>>
>>> 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
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200604/75737e7a/attachment.html>