<div dir="ltr"><div>I've created a wrapper file for AppKit (see attached file), which is eventually destined to be added to the MacPorts legacy support package. I wanted to have the dev mailing list take a look at it and maybe provide me with some initial feedback before I start actually working on adding it to GitHub. In addition, I have some questions regarding the MacPorts legacy support package.<br></div><div><br></div><div>The list of #defines in the wrapper should be fairly comprehensive, at least for the changes that Apple made when they released 10.12. I have tried my best to match the style of the other wrapper files in the legacy support package. Also, I put a description inside the file. It's pretty lengthy, but I didn't know where else to put it. It didn't seem appropriate for either the MacPorts guide or the legacy support package's README file; but I also didn't want to keep all that info sitting in my own personal notes.</div><div><br></div><div>Question 1:</div><div><br></div><div>I've noticed that in MacportsLegacySupport.h and other wrapper files, __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is used for macOS version detection. I also noticed this line in MacportsLegacySupport.h:</div><div><br></div><div>/* Not needed -- #include "AvailabilityMacros.h" */</div><div><br></div><div>Would it be considered kosher to use any of the other version detection constants from AvailabilityMacros.h, such as MAC_OS_X_VERSION_MAX_ALLOWED? Or would that be considered risky/dangerous/undesirable for some reason?</div><div><br></div><div>Question 2:</div><div><br></div><div>A related question is that in MacportsLegacySupport.h, you guys use version numbers such as 101300, 1070, etc. instead of the constants that are defined in AvailabilityMacros.h, such as MAC_OS_X_VERSION_10_13, MAC_OS_X_VERSION_10_7, etc. Is there any particular reason for not using the constants and going with the actual integer numbers? It looks like not even Apple's own source code is consistent with this. In AvailabilityMacros.h, they use the version number constants MAC_OS_X_VERSION_10_*, but in other header files like assert.h, pthread.h, etc., they use the raw integers, i.e. 1070.</div><div><br></div><div>Question 3:</div><div><br></div><div>As you can see from the attached file, I am currently creating a wrapper for AppKit.h. However, in the projects that I'm trying to package for MacPorts, their code usually uses '#include <Cocoa/Cocoa.h>'; and the system Cocoa.h, in turn, has a '#import <AppKit/AppKit.h>'. Is this going to be a problem? Is the MacPorts legacy support package able to intervene and insert its wrapper files even if a project's source code doesn't directly #include/#import that specific header file, but instead, the header to be patched is nested somewhere inside a tree/chain of header #includes?<br></div><div><br></div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div></div></div>