Some questions regarding MacPorts legacy support package
Jason Liu
jasonliu at umich.edu
Sat Jul 4 20:44:59 UTC 2020
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.
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.
Question 1:
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:
/* Not needed -- #include "AvailabilityMacros.h" */
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?
Question 2:
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.
Question 3:
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?
--
Jason Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200704/2880c112/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AppKit.h.zip
Type: application/zip
Size: 3761 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200704/2880c112/attachment-0001.zip>
More information about the macports-dev
mailing list