> On 4 Jun 2020, at 5:50 am, Jason Liu <jason...@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 <jason...@umich.edu > <mailto:jason...@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 <jon...@hep.phy.cam.ac.uk > <mailto:jon...@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 > <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 <jason...@umich.edu >> <mailto:jason...@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 >> <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 >
smime.p7s
Description: S/MIME cryptographic signature
