Xcode configuration woe

[Vincent Habchi]

Folks,

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);
^
—
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. Question: how to make clang use that header instead of the one installed in /System? Also, did I miss something?

Thanks,
Vincent

[Ryan Schmidt]

Post by Vincent Habchi
—
/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

Post by Vincent Habchi
-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.

Post by Vincent Habchi
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.

[Vincent Habchi]

Ryan,

Post by Ryan Schmidt
Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.

[…]

Post by Ryan Schmidt
So you must be on macOS 10.13 with Xcode 10.
uname -a

Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64

As you can see, I even run a beta of 10.14.2.

Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
total 43720
-rwxr-xr-x 1 root wheel 47503104 4 Nov 09:31 AppKit
-rw-r--r-- 1 root wheel 309176 25 Jul 18:33 AppKit.tbd
drwxr-xr-x 259 root wheel 8288 25 Jul 18:33 Headers
drwxr-xr-x 3 root wheel 96 25 Jul 18:33 Modules
drwxr-xr-x 77 root wheel 2464 7 Nov 22:57 Resources
drwxr-xr-x 8 root wheel 256 21 Sep 05:59 XPCServices
drwxr-xr-x 3 root wheel 96 7 Nov 22:57 _CodeSignature

Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
total 1328
-rw-r--r-- 1 root wheel 301352 15 Mar 2018 AppKit.apinotes
-rw-r--r-- 1 root wheel 8613 15 Mar 2018 AppKit.h
-rw-r--r-- 1 root wheel 1920 15 Mar 2018 AppKitDefines.h
[…]

All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.

I have Xcode 10.1 installed, and:

Air > xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Weird, no?

Vincent

[Chris Jones]

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.

[…]

Post by Ryan Schmidt
So you must be on macOS 10.13 with Xcode 10.
uname -a

Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
As you can see, I even run a beta of 10.14.2.
Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
total 43720
-rwxr-xr-x 1 root wheel 47503104 4 Nov 09:31 AppKit
-rw-r--r-- 1 root wheel 309176 25 Jul 18:33 AppKit.tbd
drwxr-xr-x 259 root wheel 8288 25 Jul 18:33 Headers
drwxr-xr-x 3 root wheel 96 25 Jul 18:33 Modules
drwxr-xr-x 77 root wheel 2464 7 Nov 22:57 Resources
drwxr-xr-x 8 root wheel 256 21 Sep 05:59 XPCServices
drwxr-xr-x 3 root wheel 96 7 Nov 22:57 _CodeSignature
Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
total 1328
-rw-r--r-- 1 root wheel 301352 15 Mar 2018 AppKit.apinotes
-rw-r--r-- 1 root wheel 8613 15 Mar 2018 AppKit.h
-rw-r--r-- 1 root wheel 1920 15 Mar 2018 AppKitDefines.h
[…]
All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.
Air > xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
Weird, no?

Not necessarily. You are running beta versions. Anything is possible.

Do you really need do this ? Wouldn't switching to the production version not make sense now ?

Chris

Post by Vincent Habchi
Vincent

[Vincent Habchi]

Post by Chris Jones

Post by Vincent Habchi
Weird, no?

Not necessarily. You are running beta versions. Anything is possible.
Do you really need do this ? Wouldn't switching to the production version not make sense now ?

How do you mean?

V.

[Chris Jones]

Post by Vincent Habchi

Post by Chris Jones

Post by Vincent Habchi
Weird, no?

Not necessarily. You are running beta versions. Anything is possible.
Do you really need do this ? Wouldn't switching to the production version not make sense now ?

How do you mean?

Isn't it obvious ? Beta releases are more likely to have problems...

Post by Vincent Habchi
V.

[Vincent Habchi]

Chris,

Isn't it obvious ? Beta releases are more likely to have problems…

I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

V.

[Chris Jones]

Post by Vincent Habchi
Chris,

Isn't it obvious ? Beta releases are more likely to have problems…

I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

I disagree. You are running a beta OS. Anything is possible.

Post by Vincent Habchi
V.

[Vincent Habchi]

Chris,

Post by Chris Jones

Post by Vincent Habchi
I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

I disagree. You are running a beta OS. Anything is possible.

That’s a bit of a blanket statement, no? :P

Cheers,
Vincent

[Chris Jones]

Post by Vincent Habchi
Chris,

Post by Chris Jones

Post by Vincent Habchi
I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

I disagree. You are running a beta OS. Anything is possible.

That’s a bit of a blanket statement, no? :P

Yes. But also true. Looks to me like you are seeing weirdness in relation to the installation on your system. Could easily be related in someway to the beta OS you are running. They are labelled beta for a reason.

Chris

Post by Vincent Habchi
Cheers,
Vincent

[Ryan Schmidt]

Post by Vincent Habchi

Post by Ryan Schmidt
Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.

[…]

Post by Ryan Schmidt
So you must be on macOS 10.13 with Xcode 10.
uname -a

Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
As you can see, I even run a beta of 10.14.2.
Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
total 43720
-rwxr-xr-x 1 root wheel 47503104 4 Nov 09:31 AppKit
-rw-r--r-- 1 root wheel 309176 25 Jul 18:33 AppKit.tbd
drwxr-xr-x 259 root wheel 8288 25 Jul 18:33 Headers
drwxr-xr-x 3 root wheel 96 25 Jul 18:33 Modules
drwxr-xr-x 77 root wheel 2464 7 Nov 22:57 Resources
drwxr-xr-x 8 root wheel 256 21 Sep 05:59 XPCServices
drwxr-xr-x 3 root wheel 96 7 Nov 22:57 _CodeSignature
Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
total 1328
-rw-r--r-- 1 root wheel 301352 15 Mar 2018 AppKit.apinotes
-rw-r--r-- 1 root wheel 8613 15 Mar 2018 AppKit.h
-rw-r--r-- 1 root wheel 1920 15 Mar 2018 AppKitDefines.h
[…]
All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.
Air > xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
Weird, no?

Weird indeed, but I can confirm it on the Mojave buildbot worker running 10.14 (which never had the Mojave beta installed) and on my 10.14.1 system (which started out with the public betas). The system headers do not mention NSAppearanceNameDarkAqua but the headers in the 10.14 SDK do.

I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

In its current design, as I recall, MacPorts assumes that if you ask for the 10.X SDK, and you are running on 10.X, then using the SDK would be the same as using the system headers, and therefore MacPorts uses the system headers instead of the SDK.

However, 10.14 does not have the /usr/include portion of the system headers anymore. If MacPorts sees that /usr/include isn't there, then it should always supply the flags that tell it to use the SDK. If we're doing that, then you should not have seen this problem, assuming the build system uses the SDK flags correctly. Looks like this port is using using cmake, which should know how to deal with SDK flags.

Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

[Vincent Habchi]

Ryan,

Post by Ryan Schmidt
I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do so?

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.
I will follow your advice and set configure.sdkroot in macports.conf

Thanks for your help, Ryan, as always!

Vincent

[Ryan Schmidt]

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do so?

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.

When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.

However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.

Post by Vincent Habchi
I will follow your advice and set configure.sdkroot in macports.conf
Thanks for your help, Ryan, as always!
Vincent
Ryan,

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

if {${os.platform} eq "darwin" && ${os.major} == 18} {
configure.sdkroot …
}
?

If this code only gets compiled on 10.14, then that would work. But do you think (or have you tested if) this code will compile on 10.13 or earlier without the 10.14 SDK?

\r

[Christopher Jones]

Post by Ryan Schmidt

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do so?

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.

When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.
However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.

I install 10.14 in a VM yesterday, to get a clean environment to run some tests.

I did this by copying and upgrade my 10.13 VM. It is now running Xcode 10.1, and I don’t have /usr/include in it

cheers Chris

[Ryan Schmidt]

Post by Christopher Jones

Post by Ryan Schmidt

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do so?

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.

When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.
However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.

I install 10.14 in a VM yesterday, to get a clean environment to run some tests.
I did this by copying and upgrade my 10.13 VM. It is now running Xcode 10.1, and I don’t have /usr/include in it

I've updated the buildbot machine, and it also still doesn't have /usr/include. But I also haven't installed the command line tools there. Maybe if I did that, /usr/include would now show up.

[Vincent Habchi]

Ryan,

Did you file a bug report with Apple w/r to that, or do you want me to go ahead?

Post by Ryan Schmidt
I've updated the buildbot machine, and it also still doesn't have /usr/include. But I also haven't installed the command line tools there. Maybe if I did that, /usr/include would now show up.

Vincent

[Chris Jones]

Post by Vincent Habchi
Ryan,
Did you file a bug report with Apple w/r to that, or do you want me to go ahead?

Do as you like, but I suspect /usr/include being missing is not a bug
but intentional.

Post by Vincent Habchi

Post by Ryan Schmidt
I've updated the buildbot machine, and it also still doesn't have /usr/include. But I also haven't installed the command line tools there. Maybe if I did that, /usr/include would now show up.

Vincent

[Vincent Habchi]

Chris,

Do as you like, but I suspect /usr/include being missing is not a bug but intentional.

I didn’t mean that. I mean the fact that when /usr/include exists, it is filled with outdated include files.

Vincent

[Ryan Schmidt]

Post by Vincent Habchi
Ryan,
Did you file a bug report with Apple w/r to that, or do you want me to go ahead?

I haven't filed a bug report. My understanding is that as more people file bug reports about an issue with Apple, the more important Apple might consider that issue to be. So anybody who wishes to should file a bug report about this at https://bugreport.apple.com

[Vincent Habchi]

Post by Ryan Schmidt

Post by Vincent Habchi
if {${os.platform} eq "darwin" && ${os.major} == 18} {
configure.sdkroot …
}
?

If this code only gets compiled on 10.14, then that would work. But do you think (or have you tested if) this code will compile on 10.13 or earlier without the 10.14 SDK?

I don’t have a clue. All my boxes run 10.14, so I have no other way to tell than submitting it and finding out how it compiles on the various buildbots. Talk about shooting in the dark… :P

Vincent

[Ryan Schmidt]

Post by Vincent Habchi

Post by Ryan Schmidt

Post by Vincent Habchi
if {${os.platform} eq "darwin" && ${os.major} == 18} {
configure.sdkroot …
}
?

If this code only gets compiled on 10.14, then that would work. But do you think (or have you tested if) this code will compile on 10.13 or earlier without the 10.14 SDK?

I don’t have a clue. All my boxes run 10.14, so I have no other way to tell than submitting it and finding out how it compiles on the various buildbots. Talk about shooting in the dark… :P

It failed to build on the 10.11 and older buildbot workers not because of qgis3 but because of its dependency postgresql10:

https://trac.macports.org/ticket/57588

[Vincent Habchi]

Ryan,

Post by Ryan Schmidt
https://trac.macports.org/ticket/57588

Good news it built on 10.12+ though.

Turns out I’m at PostgreSQL conference today, so I’ll try to ask about that to one of the attending developers.

Thanks for giving a look!
Vincent

[Ken Cunningham]

clock_gettime is one of the functions elegantly replaced by the legacy Portgroup, FYI...

K

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
https://trac.macports.org/ticket/57588

Good news it built on 10.12+ though.
Turns out I’m at PostgreSQL conference today, so I’ll try to ask about that to one of the attending developers.
Thanks for giving a look!
Vincent

[Ryan Schmidt]

Post by Ken Cunningham

Post by Vincent Habchi
Ryan,

Post by Ryan Schmidt
https://trac.macports.org/ticket/57588

Good news it built on 10.12+ though.
Turns out I’m at PostgreSQL conference today, so I’ll try to ask about that to one of the attending developers.
Thanks for giving a look!
Vincent

clock_gettime is one of the functions elegantly replaced by the legacy Portgroup, FYI...

Yup, I mentioned that in the ticket. It should still be reported to the developers of postgresql (if it hasn't been already) so that they are aware of the problem and can fix it in their code if they want to. \r

[Vincent Habchi]

Ryan,

Post by Ryan Schmidt
Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:

if {${os.platform} eq "darwin" && ${os.major} == 18} {
configure.sdkroot …
}

?

Thanks,
Vincent