<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>However, later in the build, it looks like the MacPorts build system sets SDKROOT based off the value MACOSX_DEPLOYMENT_TARGET.</div></blockquote><div> </div>As far as I know, MacPorts does not do that.</blockquote><div><br></div><div>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'. 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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On the other hand, Blender's CMake script is attempting to detect the SDK version by using the<br><br>
xcodebuild -version -sdk macosx SDKVersion<br><br>
command. On the 10.14 Azure build, this is resulting in the 
MacPorts build system showing a value of MACOSX_DEPLOYMENT_TARGET="10.14", but the xcodebuild command returning a value of 10.15.<br><br>
I'm not quite sure how to resolve this mismatch yet, but at least I see what the problem is.</div></blockquote><div><br></div><div>If the blender build is trying to detect the sdk version using the xcodebuild command, it should be patched not to do that.</div></blockquote><div><br></div><div>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.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 27, 2020 at 5:13 PM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Aug 27, 2020, at 14:55, Jason Liu wrote:<br>
> <br>
> Yes, I see what you're talking about now. And since I've only used machines that had a single SDK installed, I've never encountered this problem.<br>
> <br>
> As far as I can tell, the value of configure.sdkroot is empty<br>
<br>
That is the case sometimes, such as when the version of the SDK that MacPorts wants is not available in the installed version of Xcode.<br>
<br>
> , which means that the cmake PortGroup sets the value of CMAKE_OSX_SYSROOT to be "/".<br>
<br>
Yes.<br>
<br>
<br>
> However, later in the build, it looks like the MacPorts build system sets SDKROOT based off the value MACOSX_DEPLOYMENT_TARGET.<br>
<br>
As far as I know, MacPorts does not do that.<br>
<br>
<br>
> On the other hand, Blender's CMake script is attempting to detect the SDK version by using the<br>
> <br>
> xcodebuild -version -sdk macosx SDKVersion<br>
> <br>
> command. On the 10.14 Azure build, this is resulting in the MacPorts build system showing a value of MACOSX_DEPLOYMENT_TARGET="10.14", but the xcodebuild command returning a value of 10.15.<br>
> <br>
> I'm not quite sure how to resolve this mismatch yet, but at least I see what the problem is.<br>
<br>
If the blender build is trying to detect the sdk version using the xcodebuild command, it should be patched not to do that.</blockquote></div>