www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Version identifiers for iOS and Apple platforms

reply Jacob Carlborg <doob me.com> writes:
Currently the `iOS` version identifier is predefined by the compiler 
when targeting iOS. This is fine. In druntime and Phobos the version 
identifier `Darwin` is used to include macOS, iOS, tvOS and watchOS. 
This is set manually when needed.

I have started to use the `AppleARM` version identifier to indicate iOS, 
tvOS and watchOS. This is set manually when needed. This is not a good 
name because on the simulators `iOS`, `TVOS` and `WatchOS` should be 
defined as well, but the simulators are running x86(-64). Therefore I 
would like to come up with a better name.

In the Apple SDK there's a header file, `TargetConditionals.h` [1] which 
defines a bunch of target specific preprocessor defines. Here's an 
extract of the relevant documentation:

TARGET_OS_MAC       - Generated code will run under Mac OS X variant
    TARGET_OS_OSX    - Generated code will run under OS X devices
    TARGET_OS_IPHONE - Generated code for firmware, devices, or simulator
       TARGET_OS_IOS - Generated code will run under iOS
       TARGET_OS_TV  - Generated code will run under Apple TV OS
       TARGET_OS_WATCH     - Generated code will run under Apple Watch OS
       TARGET_OS_BRIDGE    - Generated code will run under Bridge devices
       TARGET_OS_MACCATALYST    - Generated code will run under macOS
    TARGET_OS_SIMULATOR      - Generated code will run under a simulator

`TARGET_OS_MAC` is defined for any kind of Apple platform. We're 
currently using `Darwin` for this. `TARGET_OS_OSX` is defined for macOS, 
we're using `OSX` for this. `TARGET_OS_IPHONE` is defined for iOS, tvOS 
or watchOS. This is what I have used `AppleARM` for, so far.

Would it be better to rename `AppleARM` to `iPhone`? I'm hesitating a 
bit since I think `iPhone` sounds a bit misleading. It probably has that 
name in the header file due to backward compatibility.

When it comes to the simulators. Should we define one version identifier 
for each simulator device, like `iOSSimulator` and `watchOSSimulator`. 
Or should we just define one version identifier, like `AppleSimulator`, 
for all of them?

[1] 
https://github.com/theos/sdks/blob/master/iPhoneOS11.2.sdk/usr/include/TargetConditionals.h

-- 
/Jacob Carlborg
Feb 23 2020
next sibling parent reply Johan Engelen <j j.nl> writes:
On Sunday, 23 February 2020 at 14:26:45 UTC, Jacob Carlborg wrote:

 Would it be better to rename `AppleARM` to `iPhone`? I'm 
 hesitating a bit since I think `iPhone` sounds a bit 
 misleading. It probably has that name in the header file due to 
 backward compatibility.


I have no experience with these OSes, so my opinion doesn't count 
for much here. Maybe repost in the General forum to get more 
input?

The "ARM" part of AppleARM is also misleading (maybe more so). 
Intuitively, I feel there may be some benefit in naming things 
similar to how they are in C source. In the reserved version 
identifier documentation (the table) you can say that it applies 
to WatchOS etc. aswell...

(pretty cool you are working on this btw :))

cheers,
   Johan
Feb 23 2020
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2020-02-23 15:50, Johan Engelen wrote:


 The "ARM" part of AppleARM is also misleading (maybe more so).


That's the whole reason I started this discussion :)


 Intuitively, I feel there may be some benefit in naming things similar 
 to how they are in C source. In the reserved version identifier 
 documentation (the table) you can say that it applies to WatchOS etc. 
 aswell...


I was think about `iOSDerived` as a possible name as well.


 (pretty cool you are working on this btw :))


Thanks.

-- 
/Jacob Carlborg
Feb 23 2020
prev sibling parent reply kinke <noone nowhere.com> writes:
On Sunday, 23 February 2020 at 14:50:46 UTC, Johan Engelen wrote:

 The "ARM" part of AppleARM is also misleading (maybe more so). 
 Intuitively, I feel there may be some benefit in naming things 
 similar to how they are in C source. In the reserved version 
 identifier documentation (the table) you can say that it 
 applies to WatchOS etc. aswell...


No strong opinion either, but I agree and could live with a 
`version (iPhone)`, if that's what they chose for C.

I hope there's no need for extra simulator versions; if there's 
need for special-casing, I hope the arch version can be re-used.
Feb 23 2020
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-02-23 20:36, kinke wrote:


 I hope there's no need for extra simulator versions; if there's need for 
 special-casing, I hope the arch version can be re-used.


You mean to use `iOS` and `x86_64` to identify the simulator? I don't 
think that will be sufficient. There's also the Catalyst platform (or 
what to call it). It's iPad apps compiled for macOS. I haven't looked in 
to this platform yet but I would assume it would have both `iOS` and 
`x86_64` defined.

-- 
/Jacob Carlborg
Feb 24 2020
parent reply kinke <noone nowhere.com> writes:
On Monday, 24 February 2020 at 18:39:21 UTC, Jacob Carlborg wrote:

 On 2020-02-23 20:36, kinke wrote:


 I hope there's no need for extra simulator versions; if 
 there's need for special-casing, I hope the arch version can 
 be re-used.


 You mean to use `iOS` and `x86_64` to identify the simulator? I 
 don't think that will be sufficient. There's also the Catalyst 
 platform (or what to call it). It's iPad apps compiled for 
 macOS. I haven't looked in to this platform yet but I would 
 assume it would have both `iOS` and `x86_64` defined.


I assumed druntime etc. don't need to know whether the program 
runs in a x86 simulator or natively, and in case they do in 1-2 
places, that the arch can be used to differentiate. E.g., on 
Android we apparently don't need any simulator versions (e.g., 
even the x86[_64] `long double` format corresponds to the 
AArch{32,64} one - double or quad precision). But hey, I have no 
idea about and interest in Apple stuff.
Feb 24 2020
parent Jacob Carlborg <doob me.com> writes:
On Monday, 24 February 2020 at 19:37:14 UTC, kinke wrote:


 I assumed druntime etc. don't need to know whether the program 
 runs in a x86 simulator or natively


Yeah, perhaps that's not needed. I guess it's better to wait and 
see instead of speculating :).

--
/Jacob Carlborg
Feb 25 2020
prev sibling parent Kagamin <spam here.lot> writes:
AppleSmartDust if you're trying to differentiate proper computers.
Mar 17 2020