Xcode configuration woe

[Ryan Schmidt]

On Nov 8, 2018, at 07:16, Vincent Habchi wrote:

> I try to update QGis to 3.4.1, and stumble on that compilation error:
> 
> —
> /opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:18: error: property 'effectiveAppearance' not found on object of type '__kindof NSApplication *'
>  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
>                 ^
> /opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:46: error: use of undeclared identifier 'NSAppearanceNameDarkAqua'; did you mean 'NSAppearanceNameAqua'?
>  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
>                                             ^~~~~~~~~~~~~~~~~~~~~~~~
>                                             NSAppearanceNameAqua
> /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h:56:38: note: 'NSAppearanceNameAqua' declared here
> APPKIT_EXTERN NSAppearanceName const NSAppearanceNameAqua NS_AVAILABLE_MAC(10_9);
>                                     ^
> —

Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.

https://developer.apple.com/documentation/appkit/nsappearancenamedarkaqua?language=objc


> Alright, when I look at the file /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h, I get:
> 
> -rw-r--r--  1 root  wheel  2699 15 Mar  2018 /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h
> 
> Which means that file is one release behind (10.13 instead of 10.14). However
> 
> -rw-r--r--  1 root  wheel  3721 16 Oct 07:20 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h
> 
> Is correct.

So you must be on macOS 10.13 with Xcode 10.


> Question: how to make clang use that header instead of the one installed in /System? Also, did I miss something?

At present, the macOS 10.14 SDK or newer must be used to compile this software.

MacPorts support for forcing the use a different SDK is not very good at the moment.

You could do something like this:


# On Darwin 17 (macOS 10.13) require Xcode 10 or newer
PortGroup           xcodeversion 1.0
minimum_xcodeversions-append {17 10}

# Require the 10.14 SDK or newer
if {[vercmp ${configure.sdk_version} 10.14] < 0} {
    configure.sdk_version   10.14
}

if {${os.platform} eq "darwin" && ${os.major} < 17} {
    depends_build
    depends_lib
    depends_run
    pre-fetch {
        ui_error "${name} @${version} requires macOS 10.13 or greater."
        return -code error "incompatible macOS version"
    }
}


Ideally, upstream would fix their code so that they don't use symbols not available in the build sdk.