several messages

[Jason Liu]

On Sun, Jul 5, 2020 at 12:08 AM Fred Wright <fw at fwright.net> wrote:

>
> 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.
>

The reason why the Qemu port is probably failing is because the code in the
link that I referenced was added to Qemu in 2017. It looks like Qemu has
since removed those #defines, probably due to what you said at the end:

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.
>

My guess, however, that the more likely reason upstream projects don't
typically keep these sorts of fixes around is because they don't want it
dirtying up their code for any longer than necessary. Even if you strip out
the comment lines, the #defines in my file add up to over 100 lines of code
that upstream projects probably don't want lingering around just for the
sake of legacy support.

-- 
Jason Liu


On Sun, Jul 5, 2020 at 12:08 AM Fred Wright <fw at fwright.net> wrote:

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200705/3f0ac1e1/attachment-0001.htm>