Need help with troubleshooting Blender PR

[Jason Liu]

>
> 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'. 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.

On the other hand, Blender's CMake script is attempting to detect the SDK
>> version by using the
>>
>> xcodebuild -version -sdk macosx SDKVersion
>>
>> 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.
>>
>> I'm not quite sure how to resolve this mismatch yet, but at least I see
>> what the problem is.
>>
>
> If the blender build is trying to detect the sdk version using the
> xcodebuild command, it should be patched not to do that.
>

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.

-- 
Jason Liu


On Thu, Aug 27, 2020 at 5:13 PM Ryan Schmidt <ryandesign at macports.org>
wrote:

>
>
> > On Aug 27, 2020, at 14:55, Jason Liu wrote:
> >
> > 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.
> >
> > As far as I can tell, the value of configure.sdkroot is empty
>
> 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.
>
> > , which means that the cmake PortGroup sets the value of
> CMAKE_OSX_SYSROOT to be "/".
>
> Yes.
>
>
> > 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.
>
>
> > On the other hand, Blender's CMake script is attempting to detect the
> SDK version by using the
> >
> > xcodebuild -version -sdk macosx SDKVersion
> >
> > 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.
> >
> > I'm not quite sure how to resolve this mismatch yet, but at least I see
> what the problem is.
>
> If the blender build is trying to detect the sdk version using the
> xcodebuild command, it should be patched not to do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200828/2d22bdfd/attachment.htm>