Open hjmallon opened 1 year ago
Concrete suggestions:
IOS_DEPLOYMENT_SDK_VERSION
and use CMAKE_OSX_DEPLOYMENT_TARGET
since modern CMake uses that for all Apple platformsIPHONEOS_ROOT
/ IPHONEOS_SDK_ROOT
/ IPHONESIMULATOR_SDK_ROOT
into Hunter from polly, they are still used for non-CMake schemes. We could try to persuede CMake upstream to make variables containing these values public, since they already find them too.IOS_SDK_VERSION
in Hunter, I think they can all be replaced with something more appropriate.Perhaps the new Xcode 14+ toolchains can use the new scheme? And avoid breaking old workflows.
I would hope we can do this without breaking old/normal workflows, by which I mean recent-ish CMake versions, recent-ish iOS SDK / Xcode versions.
We can do things like
CMAKE_OSX_DEPLOYMENT_TARGET
, but have a fall back for old workflowsif (NOT CMAKE_OSX_DEPLOYMENT_TARGET AND IOS_DEPLOYMENT_SDK_VERSION)
set(CMAKE_OSX_DEPLOYMENT_TARGET "${IOS_DEPLOYMENT_SDK_VERSION}"
endif()
There are loads of edge cases of old Xcode and/or old CMake that we just wouldn't be able to test without input from whoever is using those workflows.
On the plus side we would be able to:
I would hope we can do this without breaking old/normal workflows, by which I mean recent-ish CMake versions, recent-ish iOS SDK / Xcode versions.
We can do things like
- Use
CMAKE_OSX_DEPLOYMENT_TARGET
, but have a fall back for old workflowsif (NOT CMAKE_OSX_DEPLOYMENT_TARGET AND IOS_DEPLOYMENT_SDK_VERSION) set(CMAKE_OSX_DEPLOYMENT_TARGET "${IOS_DEPLOYMENT_SDK_VERSION}" endif()
There are loads of edge cases of old Xcode and/or old CMake that we just wouldn't be able to test without input from whoever is using those workflows.
On the plus side we would be able to:
- Fix behaviour on macOS ARM64 machines building iOS
- Fix tvOS building
- Stop requiring any polly-specific behaviour for iOS builds
Would you be volunteering to take a stab at this? 😄
I can certainly start a couple of the different areas. Here at work we might just use the backwards incompatible 'fix just enough to make it work' version I have now in this branch: https://github.com/hjmallon/hunter/commits/_hm_ios_overhaul
I will keep trying to keep the changes small without messing with too much at once. I will however probably break things unless other iOS-interested people can test changes as we move forwards.
Step 1 would be merging this MR if possible: https://github.com/cpp-pm/hunter/pull/610
Merged!
Building with Hunter for iOS involves a bit of Polly magic variable mangling.
IOS_SDK_VERSION
-> set to the current SDK version used with XcodeIOS_DEPLOYMENT_SDK_VERSION
-> set to the deployment target for iOSIPHONEOS_ARCHS
-> requested architectures for the iOS device part of the outputIPHONESIMULATOR_ARCHS
-> requested architectures for the iOS simulator part of the outputIPHONEOS_ROOT
/IPHONEOS_SDK_ROOT
/IPHONESIMULATOR_SDK_ROOT
There are probably othersAlso various parts of Hunter use the variable
IOS
to determine things.IOS
is not defined by default etc).arm64
->device
, which are not true any more.I'm looking at all this stuff and it seems like it might need overhauling, but to do so without breaking existing workflows might be quite difficult, and probably requires more time than I have to devote to it. The only way I can think of to do it bit by bit would be to add slimmed down, modernised, toolchains to polly for the following (which do not set any of the hunter/polly specific magic variables), then gradually fix all the schemes to work correctly (using as much cmake as we can, and increasing the minimum cmake version where required).
Does anyone have any better ideas for how to address this stuff?