Title: Remove required (non-optional) modules from Modules/Setup.dist
Type: enhancement Stage: patch review
Components: Build Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: nascheme, yan12125
Priority: low Keywords: patch

Created on 2018-07-10 23:11 by nascheme, last changed 2018-07-11 17:40 by yan12125.

Pull Requests
URL Status Linked Edit
PR 8233 open nascheme, 2018-07-10 23:14
Messages (1)
msg321399 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2018-07-10 23:11
This is related to Issue32430.  The behavior of Modules/Setup.dist and Modules/Setup is quirky and problematic.  Issue32430 links to some of the related issues.  The problem discussed in Issue24575 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  So, I think moving them to and Modules/ 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 (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 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 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.
Date User Action Args
2018-07-11 17:40:36yan12125setnosy: + yan12125
2018-07-10 23:14:37naschemesetkeywords: + patch
pull_requests: + pull_request7770
2018-07-10 23:11:10naschemecreate