Changed references of __DARWIN__ to __APPLE__
Hi Jeremy, Were there places that __DARWIN__ was not being defined but was used? I thought CPPFLAGS had -D__DARWIN__ in configure.ac? Just curious, Peter -- Peter O'Gorman http://pogma.com
__APPLE__ is set in the compiler's built-in CPPFLAGS, so it's safer. There were places that #ifdef __DARWIN__ existed but weren't triggered. So far nothing really bad, though. The only ones I found were minor. One was in x11proto (and I think the only piece of code using that conditional was compiled with -D__DARWIN__), but it's not really critical anyways... just means some variables might start out not initialized to 0... and the other was in lndir (using lndir still linked .DS_Store). --Jeremy On Dec 12, 2007, at 06:03, Peter O'Gorman wrote:
Hi Jeremy,
Were there places that __DARWIN__ was not being defined but was used? I thought CPPFLAGS had -D__DARWIN__ in configure.ac?
Just curious, Peter -- Peter O'Gorman http://pogma.com _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Jeremy Huddleston wrote:
__APPLE__ is set in the compiler's built-in CPPFLAGS, so it's safer. There were places that #ifdef __DARWIN__ existed but weren't triggered. So far nothing really bad, though. The only ones I found were minor. One was in x11proto (and I think the only piece of code using that conditional was compiled with -D__DARWIN__), but it's not really critical anyways... just means some variables might start out not initialized to 0... and the other was in lndir (using lndir still linked .DS_Store).
Yeah, my only nit is that __APPLE__ identifies the vendor, not the OS. But Apple only ships one OS these days, and I don't imagine anyone will try to build x.org on classic or A/UX (not even sure that the tools on those systems define __APPLE__, and can't be bothered to google it). Peter -- Peter O'Gorman http://pogma.com
On Dec 12, 2007, at 10:58 AM, Peter O'Gorman wrote:
Yeah, my only nit is that __APPLE__ identifies the vendor, not the OS.
A valid point, but we tend to use __APPLE__ in changes we make to BSD and Linux code, not __DARWIN__, so at least this change makes thing more consistent.
But Apple only ships one OS these days, and I don't imagine anyone will try to build x.org on classic or A/UX (not even sure that the tools on those systems define __APPLE__, and can't be bothered to google it).
I agree using __APPLE__ will likely have little (if any) practical disadvantages, and will avoid the problem of forgetting to - D__DARWIN__ which has happened to us a few times already. - Kevin
participants (3)
-
Jeremy Huddleston
-
Kevin Van Vechten
-
Peter O'Gorman