On Nov 3, 2019, at 05:39, Jack Howarth wrote:
> On Sun, Nov 3, 2019 at 4:55 AM Ryan Schmidt wrote:
>
>> 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?
I am saying that MacPorts supplies -isysroot and -syslibroot flags in CFLAGS
and LDFLAGS when required so to do. It is required when building universal on a
PowerPC Mac running Mac OS X 10.4; when on macOS 10.14 or later without
/usr/include; or on any macOS version when the port or the user has requested
to use an SDK different from the macOS version.
Some ports install -config scripts or other artifacts of the build process that
are then used to build other ports. For example, perl might install a file with
information about its configuration, which is then used later when building
perl modules. That file might include the complete value of CFLAGS and LDFLAGS
that was used to build perl, which would include any -isysroot and -syslibroot
flags with the absolute SDK paths.
We discovered after users started upgrading from Xcode 10 (which has the 10.14
SDK) to Xcode 11 (which has the 10.15 SDK) that many users were experiencing
errors about the 10.14 SDK being missing, because its path had been baked into
something due to the above.
MacPorts used to always use SDK paths from Xcode. In MacPorts 2.6.0 it changed
to prefer SDK paths from the command line tools, and only to use Xcode paths if
"use_xcode yes" is specified in the Portfile. The command line tools SDK path
shouldn't change when Xcode is upgraded, so this problem should be reduced due
to this change.
Yes, it would be great it build systems did not bake this information into
themselves. As we discover which build systems do this, we should fix them. It
will be a never-ending process of looking out for and trying to fix these kinds
of problems.
