Feature: add Apple Catalyst support (as new os.subsystem)

[SSE4]

closes: #6259

on top of #8263 !

/cc @theodelrieu @prsolucoes

Changelog: Feature: Add Apple Catalyst support (as new os.subsystem)
Docs: conan-io/docs#1983

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[madebr]

Doesn't x86_64h stand for x86_64 haswell?
So x86_64 with all features introduced in the haswell micro-architecture?
I don't think this is anything Apple specific.

It is interesting though to be able to declare architecture tuning levels.
Conforming to x86-64-v2, x86-64-v3 x86-64-v4 ...
See https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

[SSE4]

Doesn't x86_64h stand for x86_64 haswell?

seems so, but I can't find anything in Apple's reference what does it stand for. only some external sources.

[SSE4]

cpuid.h confirms that:

* CPUID_X86_64_H_FEATURE_SUBSET and CPUID_X86_64_H_LEAF7_FEATURE_SUBSET
* indicate the bitmask of features that must be present before the system 
* is eligible to run the "x86_64h" "Haswell feature subset" slice.

[SSE4]

from mach/machine.h also:

#define CPU_SUBTYPE_X86_64_H            ((cpu_subtype_t)8)      /* Haswell feature subset */

no idea why did they bring only Haswell?

[madebr]

This is probably done to unconditionally make the extra instructions of haswell available.
The older core 2's, introduced in 2006, aren't supported anyway.
The newer SIMD instructions are faster and more energy efficient.

Catalyst is a way to run mobile iOS apps on desktop (https://developer.apple.com/tutorials/mac-catalyst/)
It's a bit of an Apple Frankenstein.
arch = armv8 (M1) or x86_64
os = Macos

Does it need special treatment?

[SSE4]

yes, it needs special treatment (like -target flag), and these x86_64h binaries are different from regular x86_64 binaries and can't be mixed.
given the fact it's just a sub-set of x86_64, it is probably needed to do it in a generic way.
it means adding other micro-architectures and their handling for all the compilers.
that falls back into the old #847 which leads to nowhere.
probably, there is not enough interest in Catalyst, so it probably doesn't worth an effort, no longer a low-hanging fruit.

[madebr]

Sorry for my dumb questions because I am no Apple guy.

You say you can't mix x86_64 and x86_64h. Why is that?

On Linux, when I compile a library with -march=haswell and another one with -march=skylake;
then an application that links to both of these will work on skylake or higher.
The same can be said to object files, compiled with different -march options.

I can only see x86_64h not working on regular x86_64 when it would make use of some special api's, only available in x86_64h.

[SSE4]

no idea, that might be an ABI difference that requires to pass arguments via AVX registers, perhaps
at least target name x86_64-apple-ios-macabi suggest that a different ABI is in use, but I can't find a doc for what macabi is exactly

[madebr]

I don't think there are differences in calling conventions between microarchitectures.
See https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions and https://wiki.osdev.org/Calling_Conventions

There might exist some exotic non-standard conventions, but those are non-standard and can be ignored.
Libraries compiled for skylake don't work on haswell because its abi is incompatible, but because it is using instructions and registers unknown to haswell.

[paulocoutinhox]

Hi,

I made in the past some changes into my conan darwin toolchain version 1.1.0 to support it. It works and run OK on macOS my iPad apps.

I removed it after Apple launch support for all iOS apps on mac with arm processor.

Here are the changes:
ezored/conan-darwin-toolchain@stable/1.1.0...stable/1.2.0

Basically you need use:

cflags.extend(["-target", "%s-apple-ios-macabi" % darwin_arch])
cflags.extend(["-miphoneos-version-min=%s" % self.options.catalyst_version])

cxxflags.extend(["-target", "%s-apple-ios-macabi" % darwin_arch])
cxxflags.extend(["-miphoneos-version-min=%s" % self.options.catalyst_version])

Where "darwin_arch" = "x86_64" and "miphoneos-version-min" = "13.0". Example:

cflags.extend(["-target", "x86_64-apple-ios-macabi"])
cflags.extend(["-miphoneos-version-min=13.0"])

cxxflags.extend(["-target", "x86_64-apple-ios-macabi"])
cxxflags.extend(["-miphoneos-version-min=13.0"])

But to it work well you need generate a xcframework, because if you use a flat binary you will have a conflict between x86_64 for mac and x86_64 for catalyst.

Thanks.

[SSE4]

@theodelrieu for me it's currently not that clear how to model Catalyst with conan settings appropriately. e.g. should it be new os, os.sdk or new sub-settings of os? (see also #8263 which extends Apple settings).

[SSE4]

@prsolucoes unfortunately, I don't have any experience with XCFrameworks yet. do they require special treatment, or do they work just regular .frameworks?
e.g. will the following code work for XCFramework:

def package_info(self):
    self.cpp_info.frameworks = ["MyXCFramework"]

[paulocoutinhox]

Hi @SSE4

You can use on Apple XCFrameworks as frameworks. Internally xcframework is a group or framework by platform.

To generate you can use:

mkdir -p build/ios_framework/Release/xcf

xcodebuild -create-xcframework \
    -framework build/ios_framework/Release/iOS/Ezored.framework \
    -framework build/ios_framework/Release/iOS-simulator/Ezored.framework \
    -framework build/ios_framework/Release/macOS/Ezored.framework \
    -framework build/ios_framework/Release/tvOS/Ezored.framework \
    -framework build/ios_framework/Release/watchOS/Ezored.framework \
    -output build/ios_framework/Release/xcf/Ezored.xcframework

Result:

[madebr]

I think adding an extra arch is not a good idea.
By my knowledge, no new architecture is created by apple: they only have x86_64 and armv8.

This arch is going to be badly supported on cci, and other recipes. I think this needs to be a os.subsystem for Macos or something similar.

[memsharded]

I think adding an extra arch is not a good idea.
By my knowledge, no new architecture is created by apple: they only have x86_64 and armv8.

Ok, thanks for the feedback. Then I probably didn't completely understood the thread above, I deduced from it that it could be added. Please @SSE4 can you elaborate on this? Would the subsystem for apple be a better approach?

[memsharded]

Making sure we do the right decision after @madebr feedback suggesting this is not a good approach.

[SSE4]

I think adding an extra arch is not a good idea.
By my knowledge, no new architecture is created by apple: they only have x86_64 and armv8.

Ok, thanks for the feedback. Then I probably didn't completely understood the thread above, I deduced from it that it could be added. Please @SSE4 can you elaborate on this? Would the subsystem for apple be a better approach?

yes, it seems like the sub-system fits better. I'd still like to hear from @theodelrieu and @prsolucoes how do they prefer to have it modeled in settings.

[paulocoutinhox]

Hi @SSE4,

What os.subsystem mean? What it will do in real world? How os.subsystem will affect compiler params?

You need something to change two settings for cflags and cxxflags:

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

[SSE4]

Hi @SSE4,

What os.subsystem mean? What it will do in real world? How os.subsystem will affect compiler params?

You need something to change two settings for cflags and cxxflags:

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

you're right, under the hood, inside the conan client, it will be:

if self.settings.os.subsystem == "Catalyst":
    cflags.extend(["-target = x86_64-apple-ios-macabi", "-miphoneos-version-min = 13.0"])

I am more concerned with user experience now. e.g. catalyst might be an top-level os on its own, or os.subsystem sub-setting of the iOS (or Macos?), or it might use os.sdk, or whatever else.

anyway, we need to somehow distinguish Catalyst from the regular Macos/iOS, and we need to express it with conan settings somehow as well.

[paulocoutinhox]

Humm, now im understand how you organize it under the code.

I think that "catalyst" is a subsystem, because it still x86_64, so it "only run on macos" and not ios. It don't work on iOS, but use something from this only to build things related to UI (uikit). So "catalyst" is a subsystem for macos that use special flags to build a desktop app with ios things, but still related to macos.

You can see here the words of apple:
https://developer.apple.com/mac-catalyst/

Native Mac apps built with Mac Catalyst can share code with your iPad apps, and you can add more features just for Mac. In macOS Big Sur, you can create even more powerful versions of your apps and take advantage of every pixel on the screen by running them at native Mac resolution. Apps built with Mac Catalyst can now be fully controlled using just the keyboard, access more iOS frameworks, and take advantage of the all-new look of macOS Big Sur. There’s never been a better time to turn your iPad app into a powerful Mac app.

It still a "native mac app". It can "share" swift code with iOS when you create a iOS app. Mac catalyst "access" ios framework, but still a mac app.

Based on all this, in my opinion, it is a subset of macos normal app.

[dmn-star]

@SSE4 You can use the x86_64-apple-ios13.0-macabi target only
if self.settings.os.subsystem == "Catalyst":
cflags.extend(["-target = x86_64-apple-ios13.0-macabi"])

[SSE4]

okay, so the plan is:

• add os.subsystem sub-settings for macOS (right away, the only possible sub-settings will be catalyst and None)
• ensure -target=x86_64-apple-ios-macabi flag is set (check AutoToolsBuildEnvironment and CMake)
• seems like x86_64h arch isn't needed (at least for now)

I'll wait for the #8263 and update this one (otherwise they will conflict)

[paulocoutinhox]

okay, so the plan is:

• add os.subsystem sub-settings for macOS (right away, the only possible sub-settings will be catalyst and None)
• ensure -target=x86_64-apple-ios-macabi flag is set (check AutoToolsBuildEnvironment and CMake)
• seems like x86_64h arch isn't needed (at least for now)

I'll wait for the #8263 and update this one (otherwise they will conflict)

You need set the min version. Options:

-target=x86_64-apple-ios13.0-macabi

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

Or i think that we can set only -target = x86_64-apple-ios-macabi and let users define their min-version to 13.0 or other.

What will be the behaviour?

[SSE4]

okay, so the plan is:

• add os.subsystem sub-settings for macOS (right away, the only possible sub-settings will be catalyst and None)
• ensure -target=x86_64-apple-ios-macabi flag is set (check AutoToolsBuildEnvironment and CMake)
• seems like x86_64h arch isn't needed (at least for now)

I'll wait for the #8263 and update this one (otherwise they will conflict)

You need set the min version. Options:

-target=x86_64-apple-ios13.0-macabi

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

Or i think that we can set only -target = x86_64-apple-ios-macabi and let users define their min-version to 13.0 or other.

What will be the behaviour?

the min-version is already set for all other Apple platforms if os.version is defined.

[paulocoutinhox]

okay, so the plan is:

• add os.subsystem sub-settings for macOS (right away, the only possible sub-settings will be catalyst and None)
• ensure -target=x86_64-apple-ios-macabi flag is set (check AutoToolsBuildEnvironment and CMake)
• seems like x86_64h arch isn't needed (at least for now)

I'll wait for the #8263 and update this one (otherwise they will conflict)

You need set the min version. Options:

-target=x86_64-apple-ios13.0-macabi

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

Or i think that we can set only -target = x86_64-apple-ios-macabi and let users define their min-version to 13.0 or other.
What will be the behaviour?

the min-version is already set for all other Apple platforms if os.version is defined.

ok

[dmn-star]

okay, so the plan is:

• add os.subsystem sub-settings for macOS (right away, the only possible sub-settings will be catalyst and None)
• ensure -target=x86_64-apple-ios-macabi flag is set (check AutoToolsBuildEnvironment and CMake)
• seems like x86_64h arch isn't needed (at least for now)

I'll wait for the #8263 and update this one (otherwise they will conflict)

You need set the min version. Options:

-target=x86_64-apple-ios13.0-macabi

-target = x86_64-apple-ios-macabi
-miphoneos-version-min = 13.0

Or i think that we can set only -target = x86_64-apple-ios-macabi and let users define their min-version to 13.0 or other.
What will be the behaviour?

the min-version is already set for all other Apple platforms if os.version is defined.

But here is no dependence between macOS (os.version) version and iOS version (-miphoneos-version-min = 13.0).

PS: yes, x86_64h arch is not required for Catalyst.

[SSE4]

rebased on top of #8263 :

• no longer adds x86_64h architecture
• add new os.subsystem for Macos with possible values: [None, "Catalyst"]
• ensures -target=x86_64-apple-ios-macabi is activated for Catalyst
• ensures -mios-version-min is used for Catalyst
• tools.apple_deployment_target_flag accepts os.subsystem as an optional argument

[memsharded]

Looking good, needs to merge develop and solve conflicts now that the os.sdk PR has been merged.

[SSE4]

@memsharded rebased