Need help with troubleshooting Blender PR

[Jason Liu]

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, which means
that the cmake PortGroup sets the value of CMAKE_OSX_SYSROOT to be "/".
However, later in the build, it looks like the MacPorts build system sets
SDKROOT based off the value MACOSX_DEPLOYMENT_TARGET.

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.

-- 
Jason Liu


On Wed, Aug 26, 2020 at 10:27 PM Joshua Root <jmr at macports.org> wrote:

> On 2020-8-27 11:40 , Jason Liu wrote:
> > Hi everyone,
> >
> > I've submitted a PR
> > <https://github.com/macports/macports-ports/pull/8236> for my Blender
> > port, but all of the Travis builds are failing. A short time ago, I had
> > access to a friend's 10.15 machine (with Xcode 11.5, I believe) for
> > about a week, and I was able to compile the port locally on that
> > machine. Can anyone with 10.15 or 10.14 grab the files from the PR and
> > see whether my port builds locally for you?
>
> Looking at the 10.14 Azure build, the problem seems to be that both the
> 10.14 and 10.15 SDKs are being used. You likely need to convince the
> build system to use what is specified in configure.sdkroot instead of
> autodetecting the SDK.
>
> Anyone who only has a single SDK on their system would not be able to
> reproduce the issue.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200827/80d7e7b9/attachment.htm>