On Wed, 3 Jun 2020, Jason Liu wrote:
[...]
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:
[...]
It's interesting that you cite Qemu as an example of this, when the Qemu
port is currently failing to build on 10.9 for reasons that look very
similar to this issue.
On Sat, 4 Jul 2020, Ken Cunningham wrote:
Some questions regarding MacPorts legacy support package
Jason Liu jasonliu at umich.edu
<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>
Sat Jul 4 20:44:59 UTC 2020
[...]
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?
We have tried to make this (so far) such that this was not needed, and
just go with the compiler default
“__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.
I'm not sure where this "__ENVIRONMENT" prefix is coming from. Is that a
version of the definitions created by legacy-support?
Normally, there are four macros of this form available:
__MAC_OS_X_VERSION_MIN_REQUIRED
__MAC_OS_X_VERSION_MAX_ALLOWED
MAC_OS_X_VERSION_MIN_REQUIRED
MAC_OS_X_VERSION_MAX_ALLOWED
The general idea is that MIN_REQUIRED is for features that weren't
available before a certain OS version, and MAX_ALLOWED is for features
that were *removed* after a certain OS version. Since OS versions mostly
try to be backward compatible with older versions, the first one is useful
far more often than the second. As a general rule, if you're not sure
which one you want, then you almost certainly want MIN_REQUIRED.
Since having those defined differently would only be expected in cases
where the build target is a range of OS versions, and since MacPorts has
no concept of "OS version universality" and hence always targets one
specific OS version, once would expect the two definitions to be the same
in the MacPorts environment. But aside from it being cleaner to use the
correct macro for the context, there's at least one case where they're
*not* the same. From the default compiler on 10.5.8:
MacMini:OSX fw$ ./conftest
__APPLE__ = 1
__MAC_OS_X_VERSION_MIN_REQUIRED = 1058
__MAC_OS_X_VERSION_MAX_ALLOWED = 1060
_POSIX_VERSION = 200112
Thus, using MAX_ALLOWED to distinguish 10.5 from 10.6 doesn't work. There
are several ports that don't build on 10.5 for precisely this reason.
As far as the double-undersore versus non-double-underscore aspect is
concerned, the double-underscore versions are usually defined by the
compiler itself (with no includes), but sometimes not, in which case it's
necessary to include Availability.h (but *not* necessarily
AvailabilityMacros.h). The non-double-underscore versions are defined in
AvailabilityMacros.h. Hence, any use of those demands including
AvailabilityMacros.h.
If anyone can explain why there's ever a reason to use the
non-double-underscore versions, I'd like to hear it. Otherwise, doing so
is simply adding a dependency on an include that might not otherwise be
needed, and the double-underscore versions are preferable.
This is also something which some ports get wrong and have broken builds
or missing features as a consequence.
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.
We are sticking with the numbers. See this
<https://trac.macports.org/wiki/LeopardSDKFixes#Incorrect__MAC_OS_X_VERSION_MAX_ALLOWED>
for the initial inspiration for that, but it just avoids a lot of
confusion about which constants are available in which files and when.
Yes, the basic problem is that older includes don't have the newer
definitions. So in general, if you want to support a wide range of OS
versions, it's best to stick to the numeric constants.
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?
This will be — something new. Nobody actually knows how well this will work.
It's also worth noting that this particular kind of fix probably only
needs include additions and no library additions, which is something the
PortGroup may not be set up to handle. Of course some ports may need the
added library for *other* reasons, and that needs to be handled correctly.
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.
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.
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.
In general, direct upstream support seems preferable when possible, but
some upstream developers refuse to support old OS versions, sometimes
using "security" as a lame justification.
Fred Wright
