Re: Ubuntu and Debian packages / 2013-07-07

[Graham Lee]

On 9 Jul 2013, at 08:38, "Wolfgang Lux" <wolfgang.lux@gmail.com> wrote:

> Richard Frith-Macdonald wrote:
> 
>> 
>> On 9 Jul 2013, at 07:37, Graham Lee <graham@iamleeg.com> wrote:
>> 
>>> On 9 Jul 2013, at 05:34, "Richard Frith-Macdonald" 
>>> <richardfrithmacdonald@gmail.com> wrote:
>>> 
>>>> I'd appreciate any information from OSX coders about what we should 
>>>> actually be doing.
>>> 
>>> Hi Richard,
>>> 
>>> Here's one explanation of the macros from someone within Apple:
>>> 
>>> http://lists.apple.com/archives/xcode-users/2005/Aug/msg00399.html
>>> 
>>> …min_allowed and …max_defined act as sort of brackets for client code to 
>>> select different paths based on what OS X SDK they're compiling for.
>>> 
>>> To me, it doesn't make sense for GNUstep to define them. On 
>>> apple-apple-apple, API availability is determined by the Apple frameworks. 
>>> On gnu-gnu-gnu, API availability is a moving target, and something that 
>>> doesn't correspond cleanly to any one Apple release, now or at any other 
>>> time.
>>> 
>>> My suggestion would be for such tests to consistently pass or fail in 
>>> GNUstep, with recommendation that people who have code that depends on them 
>>> have a condition that explicitly satisfies #ifdef GNUSTEP with behaviour 
>>> correct for the release of -base/-GUI they're using.
>> 
>> Thanks ... that's kind of what I thought the position was when I removed the 
>> define of MAC_OS_X_VERSION_MAX_ALLOWED
>> So maybe IK was right, and I should remove it again.
>> 
>> But ... what about people porting OSX code to GNUstep?  If we define this 
>> then presumably there's a bigger chance that they can just take their OSX 
>> source and compile it unchanged.
> 
> I'd say we should define this macro and set it to the highest OS X version 
> whose APIs we currently support. 
> 

That is, AFAIK, none of them. OS X version tests are too general to have 
meaning outside OS X. Someone could be testing the version to get AppleScript 
compatibility, or some Quartz function, or to know whether Carbon APIs can be 
used. In many of those cases the answer would be "no" for a GS platform.

My suggestion is to err on the side of false negatives ("you said we had to do 
this instead of that, when both work") rather than false positives ("you said 
we could do this but we can't").

Cheers,

Graham.