SetOSX_SDK.cmake overrides requested `CMAKE_OSX_SYSROOT`

[cho-m]

Check duplicate issues.

• Checked for duplicates

Description

Seen while building 6.40.00 in Homebrew

• root 6.40.00 Homebrew/homebrew-core#283822

At Homebrew, we pass in a specific -DCMAKE_OSX_SYSROOT=... to select the correct SDK we need to build for our distribution. This avoiding using incorrect CLT SDKs and/or Xcode SDKs that are installed on runner and aligns with all other packages we ship.

It looks like the new SetOSX_SDK.cmake does not respect this, even though comment claims it does:

root/cmake/modules/SetOSX_SDK.cmake

Lines 7 to 10 in 9d249c3

	# To choose an SDK, one has the following options:
	# - Let xcrun choose the latest installed SDK: "cmake ..."
	# - Configure an SDK using "SDKROOT=<path> cmake ..."
	# - Set a cache variable: "cmake -DCMAKE_OSX_SYSROOT=<path> ..."

Main issue is the usage of ${...} to check if defined rather than the variable itself. Pretty much an if(TRUE) right now:

root/cmake/modules/SetOSX_SDK.cmake

Line 19 in 9d249c3

if(NOT DEFINED "${CMAKE_OSX_SYSROOT}")

Reproducer

1. Unpack https://root.cern/download/root_v6.40.00.source.tar.gz
2. cmake -Bbuild -DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk (or other installed SDK, ignoring other options as visible without them)
3. See output. In my case, I also have Xcode.app installed. In Homebrew CI, the wrong CLT SDK gets picked which causes build to fail.

   -- Mac OS SDK version: '26.5' /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
   

ROOT version

6.40.00

Installation method

Building from source (for Homebrew distribution)

Operating system

macOS

Additional context

When wrong SDK is picked, the build fails on handling <filesystem> detection - https://github.com/Homebrew/homebrew-core/actions/runs/26187130966/job/77067037892#step:3:155

  CMake Error at cmake/modules/SearchInstalledSoftware.cmake:1775 (message):
    Could not determine how to use C++17 <filesystem>
  Call Stack (most recent call first):
    CMakeLists.txt:134 (include)

[vepadulano]

Dear @cho-m ,

Thanks for the report! I agree the current logic is wrong, it was probably an oversight, apologies. This will probably come up also on the conda-forge build, which will start very soon testing for 6.40, to be confirmed. In any case, I have opened a PR to fix it.