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 <[email protected]> wrote: > Hi, > > On 4 Jun 2020, at 3:06 pm, Jason Liu <[email protected]> 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 <[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 >>>> >>>> >>>> >> >
