On Aug 28, 2020, at 09:55, Jason Liu wrote:
>>> However, later in the build, it looks like the MacPorts build system sets
>>> SDKROOT based off the value MACOSX_DEPLOYMENT_TARGET.
>>
>> As far as I know, MacPorts does not do that.
>
> Then it's possible that CMake is doing that. Regardless, if you take a look
> at the build log from either the 10.14 or 10.15 Azure builds, somehow an
> environment variable with the name SDKROOT is somehow getting set. The
> interesting thing, and something I haven't yet been able to figure out, is
> that the build log on my local machine with macOS 10.11 and Xcode 8.2.1 does
> not show this environment variable at all, even when I am doing a 'port -vst
> install'.
MacPorts base sets the SDKROOT environment variable to the value of
${configure.sdkroot} if the value of ${configure.sdkroot} is not empty. By
default, it is not empty on macOS 10.14 and later (because in 10.14 Apple
removed the headers from /), and it is empty on 10.13 and earlier.
> One more observation is that the value of this mysterious SDKROOT variable is
> getting set to '/Library/Developer/CommandLineTools/...' in the 10.14 Azure
> build, but is getting set to
> '/Applications/Xcode_11.6.app/Contents/Developer/...' in the 10.15 Azure
> build.
Then I guess the 10.14 Azure build machine has the command line tools installed
and the 10.15 Azure build machine does not. MacPorts is designed to use the CLT
if available, and to use Xcode if the port says "use_xcode yes" or if the CLT
is not available.
> Theoretically, I shouldn't need a patch to do that. Blender's CMake script
> only runs through its SDK detection code using the xcodebuild command if the
> OSX_SYSTEM variable doesn't exist. I should be able to circumvent that code
> by simply setting a value for OSX_SYSTEM as one of the configure.args in the
> portfile.
Ok great, if the build system supports setting a variable for that, then do
that.
