On Dec 4, 2007, at 11:36 AM, Miller Puckette wrote:
furthermore, having _WIN32 defined on w64 is an _ugly_ hack on micro$oft's side, there is no need to support that. MSW (if it is kept) could/should be defined for both w32 and w64, and it should be automatically defined (that is: not within the makefile but within a central place, like m_pd.h)
mfga.sdr IOhannes
but how could m_pd.h determine its platform without help from the makefile? Especially since there seems to be no guarantee about future presence of macros like _WIN32?
There is as much a guarantee that _WIN32 will exist as Windows itself will exist. It is used in Cygwin, MySQL, gcc, etc. For example, _WIN32 has been in gcc since at least '97:
http://gcc.gnu.org/ml/gcc-bugs/1997-12/msg00401.html
I personally would also prefer to avoid using __linux__ and other such "dark" defines in favor of having the build system take care of figuring the platform out. Unfortunately, I haven't been consistent myself about this (grep #if *.c | fgrep __ | wc returns 40).
Using automatic defines like __APPLE__, _WIN32, and __linux__ are the standard practice for basically all coding environments. The make code more readable since you only need to remember the one macro and don't have to learn each person's custom macros. And worst comes to worst, and they somehow vanish, you can just do a -D_WIN32 as easily as you can do a -DMSW.
But really, what should be happening is less reliance on these OS macros throughout the code, and instead using the autoconf HAVE_ENDIAN_H style macros. In the code, it rarely matters what platform it is, the real issue is usually whether a specific feature or header exists.
.hc
------------------------------------------------------------------------ ----
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf