Re: XCode 11.1 + Mac OS X 10.14.6 + pkgsrc 2019Q3

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 10/11, J. Lewis Muir wrote:
> On 10/11, Edgar Fuß wrote:
> > EF> You need to download the SDK for the older macOS version.
> > EF> The downloads are somewhat hidden, but I explained how to find them.
> > 
> > LM> I don't understand how this works.  On macOS Mojave 10.14.5, Xcode 11.1
> > LM> appears to come with one macOS SDK, namely 10.15:
> >
> > Depends on what you mean by "how this works".
> 
> I meant how I could select a deployment target of 10.6 and seemingly
> build an app for it just fine in Xcode yet only have the latest 10.15
> SDK.  Is it using weak linking?  Will it not tell me if I use something
> from a newer SDK (i.e., 10.7 to 10.15, in this case)?  If it doesn't
> tell me, then it will just fail at runtime which isn't helpful.  Is that
> why I actually need the SDK that corresponds to the deployment target so
> that I can actually tell when I'm trying to use something not available
> in the deployment target?

My conclusion after researching some more is that it's all due to weak
linking and Apple making it so that a single app can decide at run time
which API features to use based on the version of macOS it's currently
running on.  (I'm surprised this topic isn't documented thoroughly by
Apple somewhere.  At least I couldn't find it anywhere.)  The upside
is that you can do this (i.e., one app can use or not use features at
run time across a range of macOS versions).  The downside is that if
you want to just target a certain earlier API (i.e., a certain earlier
version of macOS), you don't have a good way to do this and be warned
that your app will crash when it runs on that earlier version of macOS
if you unintentionally use an API feature that does not exist in it. :-(

I believe this is why some people want earlier versions of the SDK.  If
you use the SDK that corresponds to your chosen deployment target (i.e.,
the earlier version of macOS that you want the app to be able to run
on), you will be able to check at compile time that it will work because
later API features won't exist in that SDK.  This is also why some
people will intentionally not upgrade Xcode because if the Xcode that
they have includes the SDK that corresponds to their chosen deployment
target, then they can keep it this way and not need to mess around with
multiple SDKs.

For the approach of just using the latest version of Xcode and the
latest SDK that it comes with (which seems to be what Apple thinks is a
good approach since they don't make it easy to do otherwise), it seems
quite helpful to have a product like Deploymate

  http://www.deploymateapp.com/

that will identify unavailable API usage.  If it works correctly, then
it's a great tool that eliminates the need to have multiple SDKs (in
Xcode anyway).  If not, then it's time to get the SDK that corresponds
to your chosen deployment target.

Getting the desired SDK seems to involve downloading the earlier version
of Xcode that includes the version of the SDK you want and copying the
SDK folder out of it.  MacOSX-SDKs

  https://github.com/phracker/MacOSX-SDKs

is a compilation of those.  If you don't trust that person (I don't know
them), then there are tables at

  https://en.wikipedia.org/wiki/Xcode#Version_comparison_table

that list what SDK version is included in what version of Xcode so that
you can get the desired SDKs yourself from Apple.  I haven't tried it,
but it seems you can copy an SDK folder out of an earlier Xcode without
installing that Xcode, and place the SDK folder alongside the latest SDK
in the currently installed Xcode.  Of course, if you install an update
to Xcode, you have to repeat this process since the current Xcode may
get overwritten.

Lewis