Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Add detect_api function to detect the os.sdk_version setting on macOS #16258

Open
1 task done
jwillikers opened this issue May 14, 2024 · 4 comments · May be fixed by #16355
Open
1 task done

[feature] Add detect_api function to detect the os.sdk_version setting on macOS #16258

jwillikers opened this issue May 14, 2024 · 4 comments · May be fixed by #16355
Assignees
Milestone

Comments

@jwillikers
Copy link
Contributor

What is your suggestion?

The os.sdk_version setting for macOS is one of the settings that regularly needs updated when macOS updates. It would be great if there was a detect_api function to be able to determine this value automatically in the profiles.

The output from the command xcrun --sdk macosx --show-sdk-version can be trimmed to get the exact version of the SDK, i.e. 14.5.

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Hi @jwillikers

I am having a look at this. I think it might be possible, but I'd like to understand it a bit better.

What would be the desired interface for this api? What about the --sdk macosx is this hardcoded, or macosx is an argument to the detect method that can get other values too?

@jwillikers
Copy link
Contributor Author

Hi @jwillikers

I am having a look at this. I think it might be possible, but I'd like to understand it a bit better.

What would be the desired interface for this api? What about the --sdk macosx is this hardcoded, or macosx is an argument to the detect method that can get other values too?

I was just thinking in terms of the desktop sdk, which is what macosx corresponds too, but it appears that we can use the value from settings.os.sdk as an argument for the --sdk command for iOS, watchOS, tvOS, and visionOS. Here is the output of running the xcodebuild -showsdks command for reference.

DriverKit SDKs:
    DriverKit 23.5                  -sdk driverkit23.5

iOS SDKs:
    iOS 17.5                        -sdk iphoneos17.5

iOS Simulator SDKs:
    Simulator - iOS 17.5            -sdk iphonesimulator17.5

macOS SDKs:
    macOS 14.5                      -sdk macosx14.5
    macOS 14.5                      -sdk macosx14.5

tvOS SDKs:
    tvOS 17.5                       -sdk appletvos17.5

tvOS Simulator SDKs:
    Simulator - tvOS 17.5           -sdk appletvsimulator17.5

visionOS SDKs:
    visionOS 1.2                    -sdk xros1.2

visionOS Simulator SDKs:
    Simulator - visionOS 1.2        -sdk xrsimulator1.2

watchOS SDKs:
    watchOS 10.5                    -sdk watchos10.5

watchOS Simulator SDKs:
    Simulator - watchOS 10.5        -sdk watchsimulator10.5

For the interface, the name of the sdk probably makes the best argument to a detect_api.detect_sdk_version function that returns the version of the SDK. This argument can be exactly what is passed as the value for the --sdk option. That could look something like the following in practice.

{% set sdk_version = detect_api.detect_sdk_version(sdk="macosx") %}

[settings]
os = "Macos"
os.sdk_version = {{ sdk_version }}

I think the most confusing aspect would likely be that Macos doesn't have an os.sdk setting like the other Apple operating systems.

@Neverminda
Copy link

I agree that this would be a great extension.
This detect_api extension would be very valuable if you need to switch between multiple Xcode installations.
This is necessary to prepare Conan packages during the beta phase of Xcode.

@memsharded memsharded linked a pull request May 28, 2024 that will close this issue
@memsharded
Copy link
Member

I am adding a simple method in #16355, if you want to give it a try running from source from my branch, that would be good feedback (I don't have OSX, just relying on CI)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants