Hi Martin, Reviewing the checkin message, I just saw some stuff that you added disappear: *************** *** 716,725 **** #define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE #endif - #endif - - /* Define the macros needed if on a UnixWare 7.x system. */ - #if defined(__USLC__) && defined(__SCO_VERSION__) - #define SCO_ACCEPT_BUG /* Use workaround for UnixWare accept() bug */ - #define SCO_ATAN2_BUG /* Use workaround for UnixWare atan2() bug */ - #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif --- 722,724 ---- The removed lines were added by you a few minutes earlier. I did a full cvs update, ran autoconf and autoheader, and checked in the resulting files (after testing everything first). AFAIK, pyconfig.h.in is a generated file, written by autoheader, so those #defines that you added won't stick. I'm not sure where they *should* go though. The normal way to get a variable defined in pyconfig.h.in is complicated; you have to put a template using #undef in acconfig.h.in, and call AC_DEFINE() in configure.in. I think there are a few places in configure.in where -D options are added to OPT or to CC -- I'm not sure why, it could be that the author of the patch didn't know the proper way, or it could be there was a special reason. --Guido van Rossum (home page: http://www.python.org/~guido/)
The removed lines were added by you a few minutes earlier. I did a full cvs update, ran autoconf and autoheader, and checked in the resulting files (after testing everything first).
AFAIK, pyconfig.h.in is a generated file, written by autoheader, so those #defines that you added won't stick. I'm not sure where they *should* go though.
Thanks for the notice. The right place is acconfig.h, which is the template for autoheader (autoheader also requires to put template definitions in there if it cannot determine the comment above itself). I've now corrected that.
I think there are a few places in configure.in where -D options are added to OPT or to CC -- I'm not sure why, it could be that the author of the patch didn't know the proper way, or it could be there was a special reason.
I guess it's both. Getting rid of -DINET6 is still on my agenda. In some cases, people apparently don't trust that pyconfig.h is always included before any system header. If that is guaranteed, I cannot think of any further special reason, unless there is some compiler that treats -D special (beyond defining the symbol). Regards, Martin
The removed lines were added by you a few minutes earlier. I did a full cvs update, ran autoconf and autoheader, and checked in the resulting files (after testing everything first).
AFAIK, pyconfig.h.in is a generated file, written by autoheader, so those #defines that you added won't stick. I'm not sure where they *should* go though.
Thanks for the notice. The right place is acconfig.h, which is the template for autoheader (autoheader also requires to put template definitions in there if it cannot determine the comment above itself). I've now corrected that.
Thanks. I wasn't aware that you could have regular old #ifdef and stuff in acconfig.h. How does autoconf decide which portions of the file to copy to pyconfig.h.in?
I think there are a few places in configure.in where -D options are added to OPT or to CC -- I'm not sure why, it could be that the author of the patch didn't know the proper way, or it could be there was a special reason.
I guess it's both. Getting rid of -DINET6 is still on my agenda. In some cases, people apparently don't trust that pyconfig.h is always included before any system header. If that is guaranteed, I cannot think of any further special reason, unless there is some compiler that treats -D special (beyond defining the symbol).
I think that mistrust is mistaken -- most system headers are included by Python.h, which includes pyconfig.h before any system headers. We can make a new rule: "Python.h must be included first, instead of most system headers and before any other system headers are included." --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
I think that mistrust is mistaken -- most system headers are included by Python.h, which includes pyconfig.h before any system headers. We can make a new rule: "Python.h must be included first, instead of most system headers and before any other system headers are included."
Please file a documentation bug so that I won't forget to add this information to the C API and Extending & Embedding manuals. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
Thanks. I wasn't aware that you could have regular old #ifdef and stuff in acconfig.h. How does autoconf decide which portions of the file to copy to pyconfig.h.in?
From the autoconf documentation The file that `autoheader' creates contains mainly `#define' and `#undef' statements and their accompanying comments. If `./acconfig.h' contains the string `@TOP@', `autoheader' copies the lines before the line containing `@TOP@' into the top of the file that it generates. Similarly, if `./acconfig.h' contains the string `@BOTTOM@', `autoheader' copies the lines after that line to the end of the file it generates. Either or both of those strings may be omitted. We currently use the BOTTOM part only.
I think that mistrust is mistaken -- most system headers are included by Python.h, which includes pyconfig.h before any system headers. We can make a new rule: "Python.h must be included first, instead of most system headers and before any other system headers are included."
Sounds good to me. Regards, Martin
participants (3)
-
Fred L. Drake, Jr.
-
Guido van Rossum
-
Martin von Loewis