On Sunday, May 08, 2005 12:41:26 AM -0400 Derrick J Brashear <[EMAIL PROTECTED]> wrote:
On Sat, 7 May 2005, Andres Salomon wrote:
I agree. We should try to keep the macros consistent. Furthermore, __ia64__ and AFS_IA64_LINUX20_ENV have somewhat different meanings. One means (gcc && ia64), while the other means (linux && ia64). I
gcc, or something that emulates gcc, is a requirement for compiling the Linux kernel. I don't think there's any problem with including it in the kernelspace portion of the openafs driver. My patch was only going to touched the LINUX specific directories, as it does mean (linux && ia64).
That's still sort of crappy. Why not keep what we have, but look for ways to continue to move to ifdefs by function/action/feature instead of hardcoded by system?
I agree. OpenAFS is not the Linux kernel, and it is not Linux-specific. Compiling OpenAFS does not require gcc. I would prefer to have as few OS-specific and compiler-specific assumptions as possible. Moving from using a macro which means exactly what we want it to mean and is defined exactly when we want it to be defined to one that means something different from what we are testing for and is defined depending on the whim of the compiler is _not_ an improvement.
As Derrick says, a move to feature-based macros rather than OS/platform based macros _would_ be an improvement, at least as long as such macros continue to mean exactly what we want them to mean and continue to be defined exactly when we want them to be defined.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
