I am know I am probably some of the cause of fixing header files, and my sincere apologies.
We have about 5 compiler toolsets we are using. We have GNU, Sun, IBM, M$, HP, SGI?, Cray? and ??. QNX, BSDi, Ultrix, Next, AT&T, Vax, SunOS (bsd), and ?? are all deprecated. Linux, and the BSDs (open, free, net, Apple) all are using the gnu toolsets. I realize we are worried about choking the compiler by including the same header file twice and issues about order. The issue about including the same header file twice, seems like it should be taken care of at the OS level by wrapping it in ifdefs like we do the AFS headers. Since we seem to have detailed knowledge,( maybe some of this needs to get passed back to the specific platform developers/venders... we can't be the only ones that have faced this...) The ordering issue is our issue. I assume the precompilers and headers have improved over the years and might actually take care of some of this for us. Or maybe not. =) I am just curious as to how big of a problems rxgen is really fixing with our -currently- supported systems and what platforms we seem to have the most issues with versus how many issues it is causing (like trying to clean up v7 "h/style" includes. I really don't know and I don't quite get the point of rxgen, as I have only braindeadedly stared at the code a couple of times, late at night. I won't even try to claim novice knowledge of rxgen, kernel development, multi-platform development, or development in general. If determined rxgen could be axed, the next question would simply be what would need to be in place in order for everything to work properly without it? I assume there isn't an "easy" button for this and there would have to be a (probably long) transition period. What would have to be done? And where would we end up? *curious* Sean -------------------------------------- Sean O'Malley, Information Technologist Michigan State University ------------------------------------- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
