Some questions regarding MacPorts legacy support package

[Jason Liu]

>
> This will be — something new. Nobody actually knows how well this will
> work.
>

Then I guess we're all going to find out the answer in the course of adding
this new piece, huh? :P


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

Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there
some way of making it optional?

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

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.

-- 
Jason Liu


On Sat, Jul 4, 2020 at 8:23 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> Some questions regarding MacPorts legacy support package*Jason Liu* jasonliu
> at umich.edu
> <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*
>
>
>    - Previous message (by thread): Google Magenta Portfiles Help Request
>    for new py-note-seq port
>    <https://lists.macports.org/pipermail/macports-dev/2020-July/042080.html>
>    - *Messages sorted by:* [ date ]
>    <https://lists.macports.org/pipermail/macports-dev/2020-July/date.html#42081>
>     [ thread ]
>    <https://lists.macports.org/pipermail/macports-dev/2020-July/thread.html#42081>
>     [ subject ]
>    <https://lists.macports.org/pipermail/macports-dev/2020-July/subject.html#42081>
>     [ author ]
>    <https://lists.macports.org/pipermail/macports-dev/2020-July/author.html#42081>
>
> ------------------------------
>
> 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?
>
>
>
> 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.
>
>
>
>
> 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.
>
> So — numbers.
>
>
>
> 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 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.
>
> GCC uses “fixincludes” to do much the same thing for their compiler.
>
> Thank you for your interest and help!
>
> Ken
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200705/3463937e/attachment.htm>