Re: Need help with troubleshooting Blender PR

[Joshua Root]

On 2020-8-28 10:26 , Ryan Schmidt wrote:
> 
> 
> On Aug 27, 2020, at 19:06, Joshua Root wrote:
> 
>> For that reason, we strongly prefer to use an SDK that matches the
>> deployment target. That will often only be available in the Command Line
>> Tools, which means you'll see paths in /Library/Developer even when
>> Xcode is being used.
> 
> We have seen countless cases where neither Xcode nor the command line tools 
> provide an SDK matching the OS version; it's come up in zillions of tickets.

I didn't deny that was possible; I even mentioned what happens in that case.

- Josh

Re: Need help with troubleshooting Blender PR

[Ryan Schmidt]

On Aug 27, 2020, at 19:06, Joshua Root wrote:

> For that reason, we strongly prefer to use an SDK that matches the
> deployment target. That will often only be available in the Command Line
> Tools, which means you'll see paths in /Library/Developer even when
> Xcode is being used.

We have seen countless cases where neither Xcode nor the command line tools 
provide an SDK matching the OS version; it's come up in zillions of tickets.

Re: Need help with troubleshooting Blender PR

[Joshua Root]

On 2020-8-28 05:55 , Jason Liu wrote:
> 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.

It's actually valid to use an older deployment target with a newer SDK,
but only if your code handles weak-linked symbols correctly. I don't
know if Blender does, but it's fairly uncommon in the open source world.
For that reason, we strongly prefer to use an SDK that matches the
deployment target. That will often only be available in the Command Line
Tools, which means you'll see paths in /Library/Developer even when
Xcode is being used.

The main problem seems to be the -isysroot flag pointing to the SDK
detected by the xcodebuild command, overriding the other -isysroot flag
added by MacPorts.

- Josh

Re: Need help with troubleshooting Blender PR

[Joshua Root]

On 2020-8-28 07:12 , Ryan Schmidt 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.

It should never be the case on 10.14 and later though. Even if there's
no SDK matching the chosen configure.sdk_version, it will fall back to
MacOSX.sdk and a warning will be printed.

So if configure.sdkroot is empty, something in the Portfile (or its
included PortGroups) must be clearing it.

- Josh

Re: Need help with troubleshooting Blender PR

[Ryan Schmidt]

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

Re: 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  wrote:

> On 2020-8-27 11:40 , Jason Liu wrote:
> > Hi everyone,
> >
> > I've submitted a PR
> >  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
>

Re: supertuxkart non-redistributable?

[Joshua Root]

On 2020-8-28 00:50 , Ken Cunningham wrote:
> Wikipedia got the libressl license totally wrong then, which I have not
> found is not usually the case:
> 
> 
> 
> 
> Apache License  1.0,
> 4-clause BSD License , ISC
> License , and some are public
> domain 

"4-clause BSD license" is reasonably accurate for the code taken from
OpenSSL.

- Josh

Re: supertuxkart non-redistributable?

[Ken Cunningham]

Wikipedia got the libressl license totally wrong then, which I have not found 
is not usually the case:




Apache License 1.0, 4-clause BSD License, ISC License, and some are public 
domain

anyway, we're stuck for so many ports due to that openssl PITA rider, until 
version 3.0 rolls out at least.

Ken