Need help with troubleshooting Blender PR

[Ryan Schmidt]

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.