Ah, ok. Thanks. Ya i couldn't find that email when i just googled for it again,
it's just what i remember finding when i ran into the problem and apple had
already switched over to doing the symlink thing.
Thanks
Nate
> On May 12, 2021, at 12:39 PM, Chris Jones wrote:
>
>
>
>> On 12 May 20
> On 12 May 2021, at 6:35 pm, Nathaniel W Griswold wrote:
>
> Yes, this looks right. If you are on an older 11. system you will only
> have the newest (MacOSX11.3.sdk at this time). This means that macports will
> warn you about missing SDK even though it is there and you have all the tools
Yes, this looks right. If you are on an older 11. system you will only
have the newest (MacOSX11.3.sdk at this time). This means that macports will
warn you about missing SDK even though it is there and you have all the tools
and everything builds correctly.
There was a past email on this list
On a semi-related note, relative to port build times in-general…
While building Mame locally numerous times last year, I noticed that link times
are excruciating slow: For a standard non-debug build, link times were on the
order of 10+ minutes. And for a debug build, it ballooned up to 50+ minut
To clarify my question about overcommitment: Are the total number of virtual
CPUs for the buildbot VMs running on a given Xserve, greater than the number of
physical CPU cores available?
> On 2021-05-12-W, at 08:32, Christopher Nielsen
> wrote:
>
> Looking at the build times for various ports
Looking at the build times for various ports, it varies significantly.
I was curious, are we overcommitting virtual CPUs vs. the number of available
physical cores on our Xserves? And is disk swapping coming into play, within
the VMs themselves?
I notice that the Xcode 12.5 CLT (but not Xcode 12.5) now contains a
MacOSX11.sdk symlink pointing to the MacOSX11.3.sdk. If MacPorts used
MacOSX11.sdk when available instead of the more-specific version number, it
would reduce some of the problems we have from baked-in SDK paths in some
ports.
