I don't disagree at all with your reasoning here and would certainly favor the definition of __USE_GNU at the top level, but that's a much more invasive change. The Linux kernel documentation http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html demonstrates the usage that is currently in MPICH as well as in numerous examples on the Internet... Best, Jeff On Mon, Dec 31, 2012 at 2:12 PM, William Gropp <[email protected]> wrote:
For many cases like this, the best solution is either
Never use any macro that starts with __ (these should be reserved "for the system")
If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case).
Adding it to any other header file should always be considered a mistake.
Bill
William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote:
Having been frustrated in a related development effort because I was unaware that sched.h was previously and indirectly included without the __USE_GNU macro active, thereby preventing me from using CPU_ZERO and CPU_SET, I suggest the inclusion of the following preprocessor macro in MPICH so that it is plainly obvious should this occur in the future due to the prior inclusion of sched.h before the following code, which is actually quite far down in the source.
I recognize that this is currently not a problem nor is the code below even active right now, but (1) should it ever be active and (2) some developer includes sched.h without __USE_GNU prior to line 1050 in this file (there are ~10 MPICH internal headers that could cause this right now), there will be a problem that is only detected when e.g. cpi is linked, which is later than one would otherwise prefer.
Best,
Jeff
$ svn diff pm/util/process.c Index: pm/util/process.c =================================================================== --- pm/util/process.c (revision 10808) +++ pm/util/process.c (working copy) @@ -1031,6 +1031,11 @@ #define __USE_GNU #endif #include <sched.h> + +#if !defined(CPU_ZERO) || !defined(CPU_SET) +#error CPU_ZERO and/or CPU_SET were not defined because of prior inclusion of sched.h without __USE_GNU +#endif + /* * Set the processor affinity for the calling process. Normally, this will * be used in the "postfork" routine provided by the process manager, before
-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond