[Pythonmac-SIG] wxPython build issue
kevino at theolliviers.com
Sat Feb 4 04:14:18 CET 2006
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
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. :-)
> My two penny worth
More information about the Pythonmac-SIG