Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frozen modules shouldn't be written to the source tree on Windows #113258

Closed
itamaro opened this issue Dec 18, 2023 · 3 comments
Closed

Frozen modules shouldn't be written to the source tree on Windows #113258

itamaro opened this issue Dec 18, 2023 · 3 comments
Labels
build The build process and cross-build OS-windows type-feature A feature request or enhancement

Comments

@itamaro
Copy link
Contributor

itamaro commented Dec 18, 2023

Feature or enhancement

Proposal:

As a follow-up to gh-113039, this issue suggests we change the Windows build to avoid writing the generated frozen modules back into the source tree.

Quoting @zooba

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

Links to previous discussion of this feature:

Previous discussion: gh-113039

Linked PRs

@itamaro itamaro added type-feature A feature request or enhancement OS-windows build The build process and cross-build labels Dec 18, 2023
@itamaro
Copy link
Contributor Author

itamaro commented Dec 18, 2023

for future reference, the frozen modules Windows build is in PCbuild/_freeze_module.vcxproj

@itamaro
Copy link
Contributor Author

itamaro commented 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_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.

@zooba
Copy link
Member

zooba commented Dec 20, 2023

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.

itamaro added a commit to itamaro/cpython that referenced this issue Dec 25, 2023
zooba pushed a commit that referenced this issue Jan 3, 2024
This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
@zooba zooba closed this as completed Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build OS-windows type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants