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

> Hi,
>
> On 4 Jun 2020, at 3:06 pm, Jason Liu <jasonliu at umich.edu> 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 <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/20200605/a0e58054/attachment.html>