[Pythonmac-SIG] wxPython build issue

[Kevin Ollivier]

Hi Bill,

On Feb 3, 2006, at 4:33 PM, Bill Northcott wrote:

> Hi Kevin
>
> On 04/02/2006, at 11:08 AM, Kevin Ollivier wrote:
>>> As I read the Opengroup document, Posix 200112L and Xopen 600  
>>> have been converged.  Older standards would not be the same and  
>>> certainly older versions of Xopen might have strcasecmp and  
>>> friends in string.h.  OTOH higher versions are undefined.  So it  
>>> would not be right to assume the code should work under them.   
>>> That was my take but it may be quite wrong.
>>
>> My concern is that while you're right that we can't assume that  
>> the code should work for new versions, neither can we assume it  
>> won't, so I'd prefer a solution that is guaranteed to work even if  
>> these values change. IMHO, even if we need to write a OS X-only  
>> configure test to properly set HAVE_STRCASECMP_IN_STRING_H, I'd  
>> rather go that route, because strings.h handles both scenarios  
>> (with or without the define) correctly and likely will continue to  
>> do so in the future.
>
> I quite agree that it would be best to have a solution guaranteed  
> to work in the future.  However, the standard makes it very clear  
> that these sort of behaviours may change in the future.  So it not  
> possible to use something like _XOPEN_SOURCE >= 600 with any  
> confidence.

While that argument may be theoretically true, on OS X Tiger, in  
practical terms, the value of _XOPEN_SOURCE, or even it's definition,  
doesn't matter for our purposes; the tests we need to concern  
ourselves with are all for _POSIX_C_SOURCE, and in addition, the  
tests for that in string.h and math.h simply check to see if it is  
defined. Thus, your test will do the wrong thing in cases where  
_POSIX_C_SOURCE is defined to 1, or any other value, but  
_XOPEN_SOURCE is not defined, or _XOPEN_SOURCE is defined to any  
other value than 600 (because _POSIX_C_SOURCE will be defined  
anyways). Not only in the future, but also in the present, we could  
very possibly run into cases that will break your proposed header fix.

> As for the autoconf test, IMO it is fundamentally flawed.  I have  
> checked out MacOS X, Tru64 and Solaris and in all cases the  
> operative declaration of strcasecmp() is inside multiple #ifdefs.   
> So it depends on what headers have been included first and in what  
> order.  Autoconf test programs need to be really simple and  
> reliable, which means not having a long list of included headers.   
> Unfortunately without such a list the test, as we see, is not  
> discovering what was intended.
>
> I am at a loss to see how a simple valid test might be constructed,  
> but that may be me being thick.

Well, in most cases, we don't run into problems with this approach,  
meaning that the configure test is 'good enough' in most environments  
in which it is used. So I rather think the best thing to do is to fix  
it when it breaks. In this case, thanks to the Carbon fp.h problem,  
there's really no debate as to what the fix must be - we simply can't  
have _POSIX_C_SOURCE defined for wx on Tiger, so making sure it is  
undefined at the appropriate place should fix the problem.

Otherwise, if we get rid of the configure test, we need to construct  
a completely fool-proof runtime test in the headers, and to do that,  
we'd have to look at every possible combination of #ifdef's for the  
inclusion of these functions on every supported platform, and then  
construct our own runtime test that passes in every one of those  
conditions, and fails in any other. Considering we'll probably never  
get it totally right this way either, and in the meantime we may  
break cases where the code does already work (in which case the patch  
won't be accepted anyways), I'd rather live with the configure test  
for now. :-)

Thanks,

Kevin

> My two penny worth
> Bill