CMAKE_SYSTEM_PREFIX_PATH under macOS

Usage
1

I don’t understand how the CMAKE_SYSTEM_PREFIX_PATH is set under macOS. On my system (Catalina) the currently selected SDK is:

$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

but printing the values of CMAKE_SYSTEM_PREFIX_PATH with this simple CMakeLists:

project(test)

foreach(dir ${CMAKE_SYSTEM_PREFIX_PATH})
  message(${dir})
endforeach()

the first folder is

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

and there’s no value related to /Library/Developer/CommandLineTools. My environment is clean from any reference to /Applications/Xcode.app:

$ env  
GIT_PS1_SHOWDIRTYSTATE=true
TERM=xterm-256color
SHELL=/bin/bash
TMPDIR=/var/folders/jl/gvl_b75d51lb46slt_nhznrm0000gn/T/
SSH_CLIENT=10.32.0.17 41134 22
OLDPWD=/Users/herduser
SSH_TTY=/dev/ttys000
GIT_EDITOR=vim
USER=herduser
LD_LIBRARY_PATH=/HERD/software/install//CMAKE_3.19.6/lib:
PATH=/HERD/software/install//CMAKE_3.19.6/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
PWD=/Users/herduser/test.build
PS1=[`date +%H:%M` \u@\h \W\[\e[35;1m\]$(__git_ps1 " (%s)")\[\e[0m\]]\$ 
GIT_PS1_SHOWUNTRACKEDFILES=true
SHLVL=1
HOME=/Users/herduser
GIT_PS1_SHOWSTASHSTATE=true
LOGNAME=herduser
GIT_PS1_SHOWUPSTREAM=auto
SSH_CONNECTION=10.32.0.17 41134 10.25.128.169 22
_=/usr/bin/env

so I think I’m not polluting any CMake variable. I didn’t find any useful info here so I’d need some help with this.

Using CMake 3.19.6 on macOS 10.15.4 with the following developer tools:

$ system_profiler SPDeveloperToolsDataType
Developer:

    Developer Tools:

      Version: 12.4 (12D4e)
      Location: /Applications/Xcode.app
      Applications:
          Xcode: 12.4 (17801)
          Instruments: 12.4 (64543.2)
      SDKs:
          iOS:
              14,4: (18D46)
          iOS Simulator:
              14,4: (18D46)
          macOS:
              11,1: (20C63)
              20,2: 
          tvOS:
              14,3: (18K559)
          tvOS Simulator:
              14,3: (18K559)
          watchOS:
              7,2: (18S561)
          watchOS Simulator:
              7,2: (18S561)

    Developer Tools:

      Version: 11.7 (11E801a)
      Location: /Applications/Xcode_11.7.app
      Applications:
          Xcode: 11.7 (16142)
          Instruments: 11.7 (64535.78)
      SDKs:
          iOS:
              13,7: (17H22)
          iOS Simulator:
              13,7: (17H22)
          macOS:
              10.15.6: (19G68)
              19,0: 
          tvOS:
              13,4: (17L255)
          tvOS Simulator:
              13,4: (17L255)
          watchOS:
              6,2: (17T255)
          watchOS Simulator:
              6,2: (17T255)
2

Could you please compare running

xcrun --show-sdk-path

and

xcrun --show-sdk-path --sdk macosx

?

I’ve already been in a similar situation where xcrun was returning incoherent paths. I didn’t find a way to fix it though…

3

Thanks for your reply. Here’s the info you requested:

$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
$ xcrun --show-sdk-path --sdk macosx
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk

By the way, I have two SDKs in CommandLineTools:

$ ls -l /Library/Developer/CommandLineTools/SDKs/
total 0
lrwxr-xr-x  1 root  wheel   14 May 11 18:23 MacOSX.sdk -> MacOSX11.1.sdk
drwxr-xr-x  8 root  wheel  256 Jul  9  2020 MacOSX10.15.sdk
drwxr-xr-x  7 root  wheel  224 Nov 30 13:33 MacOSX11.1.sdk

Is this OK or a misconfiguration?

4

Also, another hopefully useful info I forgot to mention. I’m using a custom built CMake, and from the build configuration after boostrap I read:

-- Found ZLIB: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libz.tbd (found version "1.2.11") 
-- Found CURL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libcurl.tbd (found version "7.64.1")

so I’d say that when building CMake the 11.1 SDK from Xcode was the current one. Maybe this has hard-coded the Xcode SDK as the default one in the CMake build, so that it is used preferentially? Anyway this does not explain the inconsistent behavior of xcrun.