This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nascheme
Recipients nascheme
Date 2018-07-10.23:11:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1531264270.58.0.56676864532.issue34089@psf.upfronthosting.co.za>
In-reply-to
Content
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 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.
History
Date User Action Args
2018-07-10 23:11:10naschemesetrecipients: + nascheme
2018-07-10 23:11:10naschemesetmessageid: <1531264270.58.0.56676864532.issue34089@psf.upfronthosting.co.za>
2018-07-10 23:11:10naschemelinkissue34089 messages
2018-07-10 23:11:10naschemecreate