You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Frozen modules shouldn't be written to the source tree on Windows #113258
I'm not sure where the relative path came from, but I don't like it. I'm also not a huge fan of generated files going back into the source tree (I prefer them in $(IntDir) so that read-only source trees are supported)
This is already the case on Linux and MacOS, so making Windows use $(IntDir) for these is also more consistent.
While we're there, consider also changing getpath.c again to include getpath.h, as suggested here.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
@zooba I made an attempt in gh-113303
it successfully generated the frozen modules (headers and deepfreeze.c) in $(IntDir), but I wasn't able to get the rest of the build to find these. I think my problem is that the generated files are written to the $(IntDir) of the _freeze_module project, which is not the same thing as the $(IntDir) of the pythoncore project. before falling into a rabbit hole about how to get one vcxproj consuming the intermediate outputs of another vcxproj, I wanted to pause and see if this is even the right direction, and whether there are other examples in the Windows build that I can borrow from.
Make sure you've got the latest from main, and then look for GeneratedPyConfigDir in pyproject.props. You'll want to do something like that for FrozenModulesDir and then reference that variable instead (it can keep the extra subdirectories so that #include works the same, but use the new property throughout the projcet files).
There's also a script to update the project files with the properties you've edited, so make sure you find and update that first and then regenerate the files. It's probably in Tools somewhere, and might be referenced from PCbuild/regen.targets, which would mean you can PCbuild/build.bat --regen to run it.
Activity
itamaro commentedon Dec 18, 2023
for future reference, the frozen modules Windows build is in
PCbuild/_freeze_module.vcxprojpythongh-113258: Write frozen modules to IntDir
itamaro commentedon Dec 20, 2023
@zooba I made an attempt in gh-113303
it successfully generated the frozen modules (headers and
deepfreeze.c) in$(IntDir), but I wasn't able to get the rest of the build to find these. I think my problem is that the generated files are written to the$(IntDir)of the_freeze_moduleproject, which is not the same thing as the$(IntDir)of thepythoncoreproject. before falling into a rabbit hole about how to get one vcxproj consuming the intermediate outputs of another vcxproj, I wanted to pause and see if this is even the right direction, and whether there are other examples in the Windows build that I can borrow from.zooba commentedon Dec 20, 2023
Make sure you've got the latest from main, and then look for
GeneratedPyConfigDirinpyproject.props. You'll want to do something like that forFrozenModulesDirand then reference that variable instead (it can keep the extra subdirectories so that#includeworks the same, but use the new property throughout the projcet files).There's also a script to update the project files with the properties you've edited, so make sure you find and update that first and then regenerate the files. It's probably in
Toolssomewhere, and might be referenced fromPCbuild/regen.targets, which would mean you canPCbuild/build.bat --regento run it.Merge branch 'main' into pythongh-113258-windows-frozen-intdir
gh-113258: Write frozen modules to the build tree on Windows (GH-113303)
pythongh-113258: Write frozen modules to the build tree on Windows (p…
pythongh-113258: Write frozen modules to the build tree on Windows (p…
pythongh-113258: Write frozen modules to the build tree on Windows (p…