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 <[email protected]> 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 >
