-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-32232: by default, Setup modules are no longer built with -DPy_BUILD_CORE #6489
Conversation
time timemodule.c # -lm # time operations and variables | ||
_thread _threadmodule.c # low-level threading interface | ||
posix -DPy_BUILD_CORE posixmodule.c # posix (UNIX) system calls | ||
errno errnomodule.c # posix (UNIX) errno values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obviously errnomodule.c does not need to be compiled with -DPy_BUILD_CORE. But is it possible that other modules in this list that build correctly now with a standard linux platform without -DPy_BUILD_CORE, may need to be build with -DPy_BUILD_CORE given some specific set of macros in pyconfig.h ? Maybe it is safer then to use -DPy_BUILD_CORE for all modules currently statically built in the interpreter (and leave the commented out modules unchanged as they are built without -DPy_BUILD_CORE in setup.py).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can treat those cases as bug reports as folks using custom pyconfig.h
files start looking at building 3.7 based versions. (Of all the ones listed, the main one I'm surprised was able to build without -DPy_BUILD_CORE
is _weakref
).
The other case where I think it would make sense to reconsider omitting the setting is if this change turns out to be a performance regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that on another platform than linux, the configure stage may define a macro in pyconfig.h
that causes one of the modules where -DPy_BUILD_CORE
is not used in the current PR (because the build does not fail for this module on linux) to require direct access to the interpreter internal for this platform. Maybe this is far-fetched.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noting the resolution of this here: https://bugs.python.org/issue32232#msg315515 (Xavier checked the modules for symbols defined in pyconfig.h.in, and this concern turns out not to apply in practice)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The essential approach looks good to me - just some comments inline regarding the specifics of naming and wording.
Makefile.pre.in
Outdated
@@ -106,7 +106,8 @@ ARFLAGS= @ARFLAGS@ | |||
# Extra C flags added for building the interpreter object files. | |||
CFLAGSFORSHARED=@CFLAGSFORSHARED@ | |||
# C flags used for building the interpreter object files | |||
PY_CORE_CFLAGS= $(PY_CFLAGS) $(PY_CFLAGS_NODIST) $(PY_CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE | |||
PY_NO_CORE_CFLAGS= $(PY_CFLAGS) $(PY_CFLAGS_NODIST) $(PY_CPPFLAGS) $(CFLAGSFORSHARED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bikeshed: perhaps PY_MODULE_CFLAGS
or PY_STDMODULE_CFLAGS
would be clearer, since these are the flags for stdlib extension modules in Modules/
that don't need direct access to the interpreter internal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PY_STDMODULE_CFLAGS
makes sense. I will make this change in the next commit.
@@ -0,0 +1,2 @@ | |||
Some modules configured in Modules/Setup are not anymore built with | |||
-DPy_BUILD_CORE. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested wording:
By default, modules configured in
Modules/Setup
are no longer built with-DPy_BUILD_CORE
. Instead, modules that specifically need that preprocessor definition include it in their individual entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much better indeed :-)
time timemodule.c # -lm # time operations and variables | ||
_thread _threadmodule.c # low-level threading interface | ||
posix -DPy_BUILD_CORE posixmodule.c # posix (UNIX) system calls | ||
errno errnomodule.c # posix (UNIX) errno values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can treat those cases as bug reports as folks using custom pyconfig.h
files start looking at building 3.7 based versions. (Of all the ones listed, the main one I'm surprised was able to build without -DPy_BUILD_CORE
is _weakref
).
The other case where I think it would make sense to reconsider omitting the setting is if this change turns out to be a performance regression.
Modules/makesetup
Outdated
@@ -233,7 +233,7 @@ sed -e 's/[ ]*#.*//' -e '/^[ ]*$/d' | | |||
case $doconfig in | |||
no) cc="$cc \$(CCSHARED) \$(PY_CFLAGS) \$(PY_CPPFLAGS)";; | |||
*) | |||
cc="$cc \$(PY_CORE_CFLAGS)";; | |||
cc="$cc \$(PY_NO_CORE_CFLAGS)";; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming the name in Makefile.pre.in
changes, it would also need to change here.
…ILD_CORE (pythonGH-6489) Setup modules are no longer built with -DPy_BUILD_CORE by default, as using that flag may now require including additional internal-only header files. Instead, only the modules that specifically need it use that setting. (cherry picked from commit 063db62) Co-authored-by: xdegaye <xdegaye@gmail.com>
GH-6547 is a backport of this pull request to the 3.7 branch. |
…ILD_CORE (GH-6489) Setup modules are no longer built with -DPy_BUILD_CORE by default, as using that flag may now require including additional internal-only header files. Instead, only the modules that specifically need it use that setting. (cherry picked from commit 063db62) Co-authored-by: xdegaye <xdegaye@gmail.com>
https://bugs.python.org/issue32232