Repository navigation
Remove required (non-optional) modules from Modules/Setup.dist #78270
Description
| BPO | 34089 |
|---|---|
| Nosy | @nascheme, @yan12125 |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2018-07-10.23:11:10.549>
labels = ['type-feature', '3.8', 'build']
title = 'Remove required (non-optional) modules from Modules/Setup.dist'
updated_at = <Date 2018-07-11.17:40:36.449>
user = 'https://github.com/nascheme'bugs.python.org fields:
activity = <Date 2018-07-11.17:40:36.449>
actor = 'yan12125'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2018-07-10.23:11:10.549>
creator = 'nascheme'
dependencies = []
files = []
hgrepos = []
issue_num = 34089
keywords = ['patch']
message_count = 1.0
messages = ['321399']
nosy_count = 2.0
nosy_names = ['nascheme', 'yan12125']
pr_nums = ['8233']
priority = 'low'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34089'
versions = ['Python 3.8']
Activity
nascheme commentedon Jul 10, 2018
This is related to bpo-32430. The behavior of Modules/Setup.dist and Modules/Setup is quirky and problematic. bpo-32430 links to some of the related issues. The problem discussed in bpo-24575 is also related (Py_BUILD_CORE not being defined when it should be because Modules/Setup is not updated after a git pull).
I think it is better if, by default, Python does not require Module/Setup to contain anything. The modules currently listed in there are not optional anyhow as they are required to run setup.py. So, I think moving them to Makefile.pre.in and Modules/config.c.in directly is better. That way, they are contained in files tracked by the VCS and the build dependencies will work as they should.
There are some downsides. First, it is more verbose in terms of source lines of code to add them directly. I suspect that is the main reason why new modules ended up in Setup.dist rather than in Makefile.pre.in (e.g. in contrast to gcmodule.c). However, a few extra lines of code seems better than a complicated build system. Modules/Setup and makesetup is complicated, for sure. For example, the Makefile depends on Setup. So, if you run "make", the Makefile can be re-generated. That is slightly crazy. Setup is created on the first run of configure but not on following runs (most people don't realize that, even I forget).
Another possible downside is that perhaps someone does not want these modules to be built-in. That would be strange as these modules are quite important and you cannot run setup.py without them. After this change, they would have to edit source code rather than a config file in order to disable these modules.
A third downside is that this change could break existing 3rd party build systems. E.g. if they create a Setup file that includes some of these always built-in modules. You will end up trying to link the same .o multiple times into "python". I expect that would cause a link error. However, if these 3rd party builds start with Setup.dist and then edit it, things should continue to work.
Rather than this approach, I considered introducing Modules/Setup.builtin. It would contain all the modules needed to run setup.py plus whatever else people wanted to include statically. The Modules/Setup.builtin file would not get the same weird treatment as Modules/Setup. I.e. Modules/Setup.builtin would be tracked by the VCS and no copy to the build folder would be made. That would take care of some issues we currently have with the build. However, I don't like that approach because it makes it more complicated to understand how things are built. With this patch, you can look at Makefile and Modules/config.c to see what is getting built.