Let ports opt in to being built for different deployment targets on buildbot

[ryandesign (Ryan Carsten Schmidt)]

We have some ports that cannot be built on older systems, even though they would run fine on older systems if compiled on a newer system. This happens especially in Mac apps and other software projects following Apple's development guidelines, which include that the developer is running on the latest macOS with the latest Xcode and the latest macOS SDK, using the latest language features.

One example is iTerm2. 3.2.x and 3.3.x claim to run on Sierra and later but 3.3.11 can only be compiled on Catalina and later.

Here's a possible solution. What if a port could indicate that it wants to opt in to a new buildbot build strategy: instead of building for each OS version on that OS version as we currently do, the port could say that it wants to build for each OS version on the latest OS version. In this situation, the buildbot would not schedule 1 build on each OS version; it would schedule multiple builds on the latest OS version. Each build would set the deployment target for the OS it's building for. Once the port is successfully built and installed, the darwin version in the archive name would have to be fixed when the archive is uploaded to the packages server.

So to follow the example through: 4 builds would get scheduled on the Catalina buildbot worker:

1. for deployment target 10.12; file renamed from iTerm2-3.3.11_0.darwin_19.x86_64.tbz2 to iTerm2-3.3.11_0.darwin_16.x86_64.tbz2 during upload
2. for deployment target 10.13; file renamed from iTerm2-3.3.11_0.darwin_19.x86_64.tbz2 to iTerm2-3.3.11_0.darwin_17.x86_64.tbz2 during upload
3. for deployment target 10.14; file renamed from iTerm2-3.3.11_0.darwin_19.x86_64.tbz2 to iTerm2-3.3.11_0.darwin_18.x86_64.tbz2 during upload
4. for deployment target 10.15; file uploaded as iTerm2-3.3.11_0.darwin_19.x86_64.tbz2

---

A different approach is to make newer toolchains available on older systems, which we already largely do, but sometimes it takes us a long time to get it all working; tapi support is one recent example. And one piece that's still missing is to provide newer SDKs to older systems, which I've worked on elsewhere.

[Wowfunhappy (Jonathan)]

Would this also require changes to Legacy Support to allow a mismatched os version and deployment target? #59135

[ryandesign (Ryan Carsten Schmidt)]

Definitely; didn't realize legacysupport didn't already support that. It needs to support that, since MacPorts allows it.