Enum to have different values for different architectures

@samRowlands

I explain how in

https://www.great-white-software.com/blog/2019/07/24/making-platform-specific-error-codes-generic/

This case is with MacOS having value 1 on Intel and value 2 on Apple Silicon.
Not sure whether Xojo can do that.

Thanks Norman.

So rule of the thumb is to create two enums. Then a thrid set of the values as constants, which can be used to tie together the two sets of enums, very clever. This is why we need you still.

However I don’t see how to specify one for Intel macOS and one for ARM macOS (which is the problem).

Why? What is the difference to TargetCarbon and TargetCocoa, or TargetMac or TargetLinux, or TargetLittleEndian and TargetBigEndian?

And if you mean “whether the CURRENT version of Xojo can do it?” then as usual terminal is your friend: according to Google the command uname -m returns the exact architecture of the machine (x86_64 or arm64 )

@MonkeybreadSoftware is referring to specifying different values in a enum for different CPU architectures (which is the problem I raised yesterday).

@npalardy suggestion is very clever, but unless I’m mistaken this is for different platforms and not CPU architectures.

“Are you merging iOS and MacOS?” At the company’s WWDC, Senior VP Craig Federighi wanted to tackle it head-on, saying, “I’d like to take a moment to briefly address this question. NO. Of course not.”

NSText.h under the macOS SDK.

#if TARGET_ABI_USES_IOS_VALUES
    NSTextAlignmentCenter    = 1,    // Visually centered
    NSTextAlignmentRight     = 2,    // Visually right aligned
#else /* !TARGET_ABI_USES_IOS_VALUES */
    NSTextAlignmentRight     = 1,    // Visually right aligned
    NSTextAlignmentCenter    = 2,    // Visually centered
#endif

I smell burning pants from over here.

Why? Sure, the code is somewhat redundant, but why would they use different values for NSTextAlignmentCenter on different platforms??? Seems to me more like a boilderplate code that reminds them “it could be or become different on the different platforms, so for future proofing always add the option to change it”

My guess is when they ported AppKit to iOS, someone changed the order of the values in the enum. Its only a problem because they’re merging the macOS and iOS and iOS compatibility takes precedence over macOS compatibility.

NSTextAlignmentCenter produces centered text on a x86 compiled application (even in Rosetta on a M1 Mac), and right aligned text on a arm executable (on a M1 Mac).

Sorry, brain-fart on my side. I could have sworn the lines were just switched, eg the enums still had the same values.

No worries.

They merged a lot of the underlaying frameworks.

Well, as there is no old macOS app using the old constants, they could easily change that.
The iOS Binaries to run on Apple Silicon Macs were already compiled with iOS constants.
The better question is why they had been different all the time anyway.

Ok what am I missing here. for both Enum and Constants… why does it matter what the rawValue is?
Isn’t that the whole point?. Unless your code is using the rawValue (in which case it should reference it from the Enum anyways)

if x = 3  /// wrong
if x=enumABC.key.rawvalue /// works regardless

I write Swift for iOS/macOS and to be honest never bothered to see if they had different values. You should not have to care