[Pythonmac-SIG] wxPython build issue

[Bill Northcott]

>> 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.

These Macros should not be defined to any old values.  Any sources  
doing that sort of thing are clearly wrong, and they should not  
accommodated except as specific exceptions.  Only certain values are  
valid.  The fix I put up only changes the existing code if  
_POSIX_C_SOURCES is 200112L.  In that case strcasecmp() and friends  
are most definitely in <strings.h>. and the fix must still work in  
all the old cases.  I don't see how the fix can break anything.

> 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.

But my suggested fix ensures that code will not break whether or not  
_POSIX_C_SOURCES is defined.  The code without the fix only works if  
it is not defined.
>
> 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. :-)

If you really want to stick with the configure test, it seems to me  
that it should at least be reversed.  That is test for <strings.h>  
first and if that works, don't bother with <string.h>.  It seems to  
me that would be more robust.  I guess it is the other way around for  
historical reasons.  In BSD 4.3 the extensions were in <string.h>.   
In BSD 4.4 and subsequent they are moved to <strings.h>.  So if  
<strings.h> works it should be right, and the systems for which it  
does not work are all going to be fairly geriatric by now.  That way  
the code would be POSIX compliant even without the other fix :-)!

Cheers
Bill