Repository navigation
De-couple the Windows builds from freezing modules. #89351
Description
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 = <Date 2021-09-16.01:15:56.780>
created_at = <Date 2021-09-13.20:44:06.042>
labels = ['type-bug', 'OS-windows', 'build', '3.11']
title = 'De-couple the Windows builds from freezing modules.'
updated_at = <Date 2021-09-16.01:15:56.779>
user = 'https://github.com/ericsnowcurrently'bugs.python.org fields:
activity = <Date 2021-09-16.01:15:56.779>
actor = 'eric.snow'
assignee = 'none'
closed = True
closed_date = <Date 2021-09-16.01:15:56.780>
closer = 'eric.snow'
components = ['Build', 'Windows']
creation = <Date 2021-09-13.20:44:06.042>
creator = 'eric.snow'
dependencies = []
files = []
hgrepos = []
issue_num = 45188
keywords = ['patch']
message_count = 10.0
messages = ['401731', '401735', '401849', '401859', '401868', '401877', '401882', '401907', '401908', '401909']
nosy_count = 6.0
nosy_names = ['gvanrossum', 'paul.moore', 'tim.golden', 'eric.snow', 'zach.ware', 'steve.dower']
pr_nums = ['28322', '28335']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45188'
versions = ['Python 3.11']
Activity
ericsnowcurrently commentedon Sep 13, 2021
Currently for Windows builds, generating the frozen modules depends on first building python.exe. One consequence of this is that we must keep all frozen module .h files in the repo (which we'd like to avoid for various reasons).
We should be able to freeze modules before building python.exe, like we already do via our Makefile. From what I understand, this will require that a subset of the runtime be separately buildable so we can use it in _freeze_module.c and use that before actually building python.exe.
@Steve, please correct any details I got wrong here. :)
zooba commentedon Sep 13, 2021
Only thing I'd add is that you should just be able to list the required .c files in _freeze_module.vcxproj (formerly known as freeze_importlib.vcxproj) rather than depending on pythoncore.vcxproj.
That will generate twice as many .obj files for those modules (which is fine, just takes a little more time at build), and will force everything to be regenerated if you modify them, but that's an expected part of having part of the interpreter depend upon itself.
ericsnowcurrently commentedon Sep 15, 2021
New changeset cbeb819 by Eric Snow in branch 'main':
bpo-45020: Freeze some of the modules imported during startup. (gh-28335)
cbeb819
zooba commentedon Sep 15, 2021
New changeset 09b4ad1 by Steve Dower in branch 'main':
bpo-45188: Windows now regenerates frozen modules at the start of build instead of late (GH-28322)
09b4ad1
gvanrossum commentedon Sep 15, 2021
Is this now done? I.e. can we now drop the frozen .h files from the repo?
zooba commentedon Sep 15, 2021
Should be able to, yeah. Though I didn't test that.
gvanrossum commentedon Sep 15, 2021
I tried this:
After each step I tried to rebuild. Each case the compilation of frozen.c failed and then the build stopped, so apparently the .h files weren't generated early enough.
Here's the error message:
C:\Users\gvanrossum\cpython\Python\frozen.c(44,10): fatal error C1083: Cannot open include file: 'frozen_modules/abc.
h': No such file or directory [C:\Users\gvanrossum\cpython\PCbuild\pythoncore.vcxproj]
ericsnowcurrently commentedon Sep 15, 2021
FYI, I have a PR up for dropping the .h files: #28375.
ericsnowcurrently commentedon Sep 15, 2021
Can we close this?
gvanrossum commentedon Sep 15, 2021
We can once #72561 lands.