Обсуждение: macOS versioned sysroot

src/tools/darwin_sysroot (previously in src/template/darwin) contains this:

# [...] Using a version-specific sysroot seems
# desirable, so if the path is a non-version-specific symlink, expand
# it.

On my system, the non-version-specific symlink is

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

and this script turns that into

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk

Now, every time the minor version of macOS is updated (e.g., 13.1 -> 
13.2), the sysroot path is no longer there and the build fails.  The fix 
is to reconfigure and rebuild.

Maybe in the past these minor versions were rare, but at the moment it 
looks like there is one about every two months.  So every two months I 
have to reconfigure and rebuild all my Postgres checkouts, of which I 
have about 20 to 30, so this is getting a bit insane.

This code has been whacked around quite a bit, so it's hard to find the 
origin of this.  But I'm going to submit a vote for "seems *not* desirable".

(There is a workaround by setting PG_SYSROOT in the environment or 
setting a meson option.  But the default shouldn't be so fragile.)

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> src/tools/darwin_sysroot (previously in src/template/darwin) contains this:
> # [...] Using a version-specific sysroot seems
> # desirable, so if the path is a non-version-specific symlink, expand
> # it.

> This code has been whacked around quite a bit, so it's hard to find the
> origin of this.  But I'm going to submit a vote for "seems *not* desirable".

The reasoning for this is in the commit log for 4823621db:

    Also, "xcrun --show-sdk-path" may give a path that is valid but lacks
    any OS version identifier.  We don't really want that, since most
    of the motivation for wiring -isysroot into the build flags at all
    is to ensure that all parts of a PG installation are built against
    the same SDK, even when considering extensions built later and/or on
    a different machine.  Insist on finding "N.N" in the directory name
    before accepting the result.  (Adding "--sdk macosx" to the xcrun
    call seems to produce the same answer as xcodebuild, but usually
    more quickly because it's cached, so we also try that as a fallback.)

    The core reason why we don't want to use Xcode's default SDK in cases
    like this is that Apple's technology for introducing new syscalls
    does not play nice with Autoconf: for example, configure will think
    that preadv/pwritev exist when using a Big Sur SDK, even when building
    on an older macOS version where they don't exist.  It'd be nice to
    have a better solution to that problem, but this patch doesn't attempt
    to fix that.

    Discussion: https://postgr.es/m/ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru

Re-reading the linked discussion makes me quite loath to remove
the version dependency logic; we'd certainly just be reinventing
that wheel next time Apple adds a new syscall that we care about.

Perhaps it would be adequate if we could select MacOSX13.sdk instead
of MacOSX13.1.sdk given the available choices:

$ ll /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x  7 root  wheel  224 Nov 12 16:18 MacOSX.sdk/
lrwxr-xr-x  1 root  wheel   10 Dec 14 10:51 MacOSX13.1.sdk@ -> MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 Dec 14 10:51 MacOSX13.sdk@ -> MacOSX.sdk

It does not seem that xcrun/xcodebuild will offer that, but we
could contemplate putting in some ad-hoc pathname munging to
strip any dot-digits part.

            regards, tom lane