On Sun, Nov 3, 2019 at 4:55 AM Ryan Schmidt <[email protected]> wrote:
> > > On Nov 3, 2019, at 03:52, Chris Jones wrote: > > > Hi, > > > > On 2 Nov 2019, at 4:56 pm, Ryan Schmidt wrote: > > > >> Josh told me when Mojave was released that we weren't installing the > CLT anymore on the builders. > >> > >> Then when Xcode 11 came along and we had zillions of problems building > things with it on Mojave without the CLT, Josh said we were changing our > recommendation back to installing the CLT. > >> > >> So that's what I then did on the Mojave builder, and when I set up the > Catalina worker. > >> > > > > Thats understandable, but the problem is upgrading Xcode to 11.2 does > not help as much when the CLT tools are still stuck at the buggy older > version, as if both are installed the older CLT SDK is now preferred, so > builds still fail. Hopefully > > > > https://github.com/macports/macports-ports/pull/5673 > > > > Will help a bit, And also hopefully Apple will not be too long in > releasing an updating CLT that is also fixed.... > > The fact that the CLT SDK is now preferred is another reason why we want > to go back to requiring the CLT. After Xcode 11 was released and Mojave > users upgraded to it, we discovered just how pervasive the problem of SDK > paths baked into build scripts was, as zillions of bug reports started > pouring in about the MacOSX10.14.sdk being missing. Having the CLT > installed on the build server ensures that any SDK paths that do get baked > in will be for something that continues to exist even if Xcode is upgraded > or is not present. > So you are saying that SDK paths are baked in as /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk (as the current CommandLineTools no longer installs in /). I'm rather surprised that folks bothered to hard code that path rather than just use `xcrun --show-sdk-path` to discover it. Is it really that hard to patch those build scripts to handle that properly? Jack
