several messages

[Fred Wright]

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