On Dec 31, 2020, at 15:54, Ken Cunningham wrote:
> On Dec 31, 2020, at 1:51 PM, Ryan Schmidt wrote:
>
>> On Dec 31, 2020, at 10:56, Ken Cunningham wrote:
>>
>>> So I will make another push for this, before we get hundreds of ports built
>>> with incorrect burned-in SDKs that make a total mess for us to manage.
>>>
>>>
>>> What is different now is that almost all current configure software does a
>>> test-compile and run rather than look for a specific header or function to
>>> be defined, and if they don’t, they will need to.
>>
>> We have a lot of non-current software in MacPorts.
>>
>> And I don't know what evidence you have that "almost all current configure
>> software" does things correctly. I find that hard to believe.
>
> Let’s test then.
>
> I have my three 10.13 systems set up with Xcode 10 and the last SDK it came
> with. Two of those are capped-out at 10.13 due to hardware, one is a VM.
>
> Happy to throw anything you like at it, and see if we can break it.
>
> You know I’m only involved in this issue to make all our lives easier,
I agree with what Josh has said many times before, that nothing has
fundamentally changed about how non-Mac software developers write their code.
They are not aware of macOS SDKs and how symbols that are available in the SDK
might not be available at runtime. It's a never-ending battle to explain this
to developers and get them to agree to accommodate it. Therefore the way to
make all our lives easier it to use the SDK that matches the OS version, and
that's what I try to do by keeping older Xcode versions on the buildbot
machines.
We want to avoid ports installing files that contain the specific SDK path.
Some ports do so only for information so it doesn't matter. Others might use
those values later to build other software, like maybe python recording the SDK
path to use it to build python modules later. In those cases, we should replace
the SDK path with the generic unversioned SDK path that exists on all systems.
This is not a new problem in macOS 11; it has been a problem anytime we use an
SDK, and certainly since 10.14.
A similar problem is when build systems save the compiler that was used into
files that get installed and then try to use that compiler later to build other
modules; perl does this. And this causes problems like
https://trac.macports.org/ticket/59786. The solution is the same: replace the
specific compiler path in the installed files (e.g.
/opt/local/bin/clang-mp-3.4) with the generic compiler (/usr/bin/cc) that
exists on all systems. (The even better solution is to explain to those
projects that they should stop saving the compiler name into their installed
files and stop trying to use it later; instead, they should always obey the CC
and CXX environment variables.)
> and specifically, so that 10.13 can get the current qt 5.15.2 on the buildbot
> so that everyone can enjoy it like I can.
That's
https://trac.macports.org/ticket/61921
and according to that, using a newer compiler might be all that's needed to get
that to work, and there may just be a bug in the qt build system that does not
accept arbitrary compilers, in which case it would be good to fix that bug. We
don't necessarily have to be the ones to figure out how to fix the bug; we can
start by reporting it to the developers of qt; maybe they will immediately know
how to fix it.
