Skip to content

Revert "Work around intermittent Windows build failure (missing pyconfig.h, etc.)" #48207

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.

Sign up for GitHub

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

Merged
chouetz merged 1 commit into from
Mar 23, 2026
Merged

Revert "Work around intermittent Windows build failure (missing pyconfig.h, etc.)" #48207

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 0 additions & 6 deletions .bazelrc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,12 +41,6 @@ common:macos --remote_local_fallback_strategy=sandboxed

# Windows config -------------------------------------------------------------------------------------------------------
common:windows --strategy=standalone # Valid values are: [dynamic_worker, standalone, dynamic, remote, worker, local]
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Restore Windows runfiles flag to avoid dual python_win builds

Removing common:windows --enable_runfiles reintroduces the Windows race that the reverted commit was masking: this repo still pins rules_python 1.9.0 (see MODULE.bazel), and deps/cpython/build_python.bat still writes intermediates into shared PCbuild paths under the source tree (PCbuild/amd64, PCbuild/obj, msbuild.rsp) instead of per-action output dirs. In that state, Bazel can schedule two python_win builds in different configs on Windows, which intermittently fails with missing/locked build artifacts (e.g., pyconfig.h), so this revert can make CI/builds flaky again until the hermetic build script fix lands.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor

@rdesgroppes rdesgroppes Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No other short-term option, alas.

# TODO(agent-build): rules_python 1.9.0 transitions py_binary to enable_runfiles=true on Windows, creating a second
# Bazel configuration. build_python.bat writes PCbuild/ intermediate files into the shared execroot source tree, so two
# concurrent builds of python_win (one per configuration) race on those files. Setting enable_runfiles globally makes
# the transition a no-op (same flag value => same config hash => one build). The proper fix is to make build_python.bat
# hermetic by redirecting MSBuild's OutDir and intermediate paths to $(@D) instead of the source tree.
common:windows --enable_runfiles
# Neither repo_env nor shell_executable affect action keys. It can be both an advantage and a disadvantage.
# For instance, if we need to have some special behavior in bash we can add it, however, in some cases
# it may lead to cache poisoning.
Expand Down
Loading