<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>This will be — something new. Nobody actually knows how well this will work.</div></blockquote><div><br></div><div>Then I guess we're all going to find out the answer in the course of adding this new piece, huh? :P<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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></blockquote><div><br></div><div>Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there some way of making it optional?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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></blockquote><div><br></div><div>A year?! If it's going to take it that long to get it incorporated into the legacy support package, then maybe I'm better off just directly adding my header to the 'files/' folder in my Blender and MaterialX ports for now? I'd really like to try to get my Blender port into the tree sooner rather than later. My portfile is written for Blender 2.82a, which was the version that was current at the start of the pandemic when I started working on the port, but since then Blender has already moved on to the 2.83 series of releases.<br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 4, 2020 at 8:23 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><blockquote type="cite"><h1 style="background-color:rgb(255,255,255)">Some questions regarding MacPorts legacy support package</h1><b style="background-color:rgb(255,255,255)">Jason Liu</b><span style="background-color:rgb(255,255,255)"> </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)" target="_blank">jasonliu at umich.edu </a><br style="background-color:rgb(255,255,255)"><i style="background-color:rgb(255,255,255)">Sat Jul 4 20:44:59 UTC 2020</i><span style="background-color:rgb(255,255,255)"></span><div style="background-color:rgb(255,255,255)"><br></div><ul style="background-color:rgb(255,255,255)"><li>Previous message (by thread): <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/042080.html" target="_blank">Google Magenta Portfiles Help Request for new py-note-seq port</a></li><li><b>Messages sorted by:</b> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/date.html#42081" target="_blank">[ date ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/thread.html#42081" target="_blank">[ thread ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/subject.html#42081" target="_blank">[ subject ]</a> <a href="https://lists.macports.org/pipermail/macports-dev/2020-July/author.html#42081" target="_blank">[ author ]</a></li></ul><hr style="background-color:rgb(255,255,255)"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">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><br></div><div>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)"><span style="white-space:pre-wrap">__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><br></div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">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><br></div><div>We are sticking with the numbers. See this <<a href="https://trac.macports.org/wiki/LeopardSDKFixes#Incorrect__MAC_OS_X_VERSION_MAX_ALLOWED" target="_blank">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><br></div><div>So — numbers.</div><div><br></div><div><br></div><br><blockquote type="cite"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">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><br></div><div>This will be — something new. Nobody actually knows how well this will work.</div><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>GCC uses “fixincludes” to do much the same thing for their compiler.</div><div><br></div><div>Thank you for your interest and help!</div><div><br></div><div>Ken</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><br></blockquote></div></blockquote></div>