<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><h1 style="background-color: rgb(255, 255, 255);" class="">Some questions regarding MacPorts legacy support package</h1><b style="background-color: rgb(255, 255, 255);" class="">Jason Liu</b><span style="background-color: rgb(255, 255, 255);" class=""> </span><a href="mailto:macports-dev%40lists.macports.org?Subject=Re%3A%20Some%20questions%20regarding%20MacPorts%20legacy%20support%20package&In-Reply-To=%3CCAHUrRf4a%2BvaF8YLE5eAh2Fo5g2ZaZTK%2BW6ecg%3DTj7tXtgx5vvg%40mail.gmail.com%3E" title="Some questions regarding MacPorts legacy support package" style="background-color: rgb(255, 255, 255);" class="">jasonliu at umich.edu </a><br style="background-color: rgb(255, 255, 255);" class=""><i style="background-color: rgb(255, 255, 255);" class="">Sat Jul 4 20:44:59 UTC 2020</i><span style="background-color: rgb(255, 255, 255);" class=""></span><div style="background-color: rgb(255, 255, 255);" class=""><br class="webkit-block-placeholder"></div><ul style="background-color: rgb(255, 255, 255);" class=""><li class="">Previous message (by thread): <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/042080.html" class="">Google Magenta Portfiles Help Request for new py-note-seq port</a></li><li class=""><b class="">Messages sorted by:</b> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/date.html#42081" class="">[ date ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/thread.html#42081" class="">[ thread ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/subject.html#42081" class="">[ subject ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/author.html#42081" class="">[ author ]</a></li></ul><hr style="background-color: rgb(255, 255, 255);" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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?
</pre></blockquote><div class=""><br class=""></div><div class="">We have tried to make this (so far) such that this was not needed, and just go with the compiler default “<span style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__” which is set to a number by every compiler on Apple/Darwin systems that matches the deployment target the compiler sees.</span></span></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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.
</pre></blockquote><div class=""><br class=""></div><div class="">We are sticking with the numbers. See this <<a href="https://trac.macports.org/wiki/LeopardSDKFixes#Incorrect__MAC_OS_X_VERSION_MAX_ALLOWED" class="">https://trac.macports.org/wiki/LeopardSDKFixes#Incorrect__MAC_OS_X_VERSION_MAX_ALLOWED</a>> for the initial inspiration for that, but it just avoids a lot of confusion about which constants are available in which files and when.</div><div class=""><br class=""></div><div class="">So — numbers.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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?
</pre></blockquote><div class=""><br class=""></div><div class="">This will be — something new. Nobody actually knows how well this will work.</div><div class=""><br class=""></div><div class="">It probably might best be something optionally used rather than a default in legacysupport, as the opportunity for unexpected wreckage seems high. On the other hand, after year or so, if it helps but doesn’t break things, it might be defaultable.</div><div class=""><br class=""></div><div class="">If a year or so sounds long, don’t worry. I wrote up the first version of legacysupport as “SnowLeopardFixes” in 2016, and it did not get really adopted until several years later, after a great deal of discussion.</div><div class=""><br class=""></div><div class="">There are still many opinions that it should not be used, and the issues / fixes sent upstream instead, but I think we’re all coming to realize that something like legacysupprt is the only way forward if we’re going to support older systems.</div><div class=""><br class=""></div><div class="">GCC uses “fixincludes” to do much the same thing for their compiler.</div><div class=""><br class=""></div><div class="">Thank you for your interest and help!</div><div class=""><br class=""></div><div class="">Ken</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><br class=""></blockquote></body></html>