On Oct 8, 2019, at 10:34, Chris Jones wrote: > On 08/10/2019 6:52 am, Ken Cunningham wrote: >>> I wonder if the SDK path is >>> baked into llvm-config-mp-7.0? >> Yep -- sheesh. Is there no end to this? >> Ken >> $ llvm-config-mp-7.0 --cflags >> -I/opt/universalnew/libexec/llvm-7.0/include -pipe -Os >> -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk >> -fPIC -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra >> -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic >> -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor >> -Wstring-conversion -DNDEBUG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 >> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > > > There seems to be a lack of rhyme or reason to what you get from llvm-config, > as it appears to vary by OS and also clang version. > > For instance, on 10.14 with 7.0 I see the same > > MacVM1014 ~ > llvm-config-mp-7.0 --cflags > -I/opt/local/libexec/llvm-7.0/include -pipe -Os > -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk > -fPIC -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra > -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic > -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor > -Wstring-conversion -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS > -D__STDC_LIMIT_MACROS > > whereas clang 8.0 on the same system gives, > > MacVM1014 ~ > llvm-config-mp-8.0 --cflags > -I/opt/local/libexec/llvm-8.0/include -D__STDC_CONSTANT_MACROS > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > > which also does not see fully correct, for different reasons. Why so short > compared to 7.0 ? > > Also, clang 7.0 on mac 10.13 gives > > Titan ~ > llvm-config-mp-7.0 --cflags > -I/opt/local/libexec/llvm-7.0/include -pipe -Os -fPIC -Werror=date-time > -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter > -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long > -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion > -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > > so there the SDK is seemingly not baked in..
10.14 is the first macOS version on which MacPorts supplies the SDK path in normal builds, because 10.14 is the first version of macOS to omit the /usr/include directory. That's why you don't see an SDK path in a 10.13 build. The fact that CFLAGS/CXXFLAGS/LDFLAGS (and thus any SDK path we supply) get baked into all sorts of places is the reason why I abandoned an earlier suggestion to always use the SDK. And then Apple released Mojave which forced us to do it anyway. https://trac.macports.org/ticket/41783#comment:14 If we used the "MacOSX.sdk" (instead of the versioned one) the fact that it gets baked into things wouldn't be a problem*. We should do this, but it will require restructuring how we do SDKs. Currently we impose a default SDK version based on the OS version, which ports can (and some do) override, so by the time MacPorts tries to see what SDK path should be used it no longer knows whether the SDK version was specifically requested or just set as a default. We should default to no SDK version. Then ports that need a specific SDK version can set it. *Well, not as much of a problem. It may still be a problem in that it's relative to either the Xcode directory or the CLT directory. If we build a binary on the buildbot, which has Xcode, and an Xcode-relative SDK path gets baked in, and a user installs that binary on a system without Xcode, they could get errors when building other ports. Now that we added the "use_xcode" Portfile variable and use the CLT SDK path for ports that don't set that, even if Xcode is installed, this part of the problem should lessen over time as ports get updated and thus rebuilt, but to make it completely go away we would have to identify all of those binary archives of ports that don't set "use_xcode yes" that were already built that contain a baked-in Xcode SDK path and rebuild those binaries so that they have CLT SDK paths.
