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 <[email protected]> wrote: > > > On 4 Jun 2020, at 5:50 am, Jason Liu <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 >>> >>> >>> >
