Looks great! Though so far, this is the part that makes me sad (watch the timestamps). I guess it's unavoidable though.

Fri, 02 May 2025 00:38:42 GMT Fetching external libraries...Fri, 02 May 2025 00:38:42 GMT Fetching bzip2-1.0.8...Fri, 02 May 2025 00:38:46 GMT Fetching mpdecimal-4.0.0...Fri, 02 May 2025 00:38:47 GMT Fetching sqlite-3.49.1.0...Fri, 02 May 2025 00:38:48 GMT Fetching xz-5.2.5...Fri, 02 May 2025 00:38:49 GMT Fetching zlib-ng-2.2.4...Fri, 02 May 2025 00:38:50 GMT Fetching external binaries...Fri, 02 May 2025 00:38:50 GMT Fetching libffi-3.4.4...Fri, 02 May 2025 00:38:51 GMT Fetching openssl-bin-3.0.16.2...Fri, 02 May 2025 00:38:53 GMT Fetching tcltk-8.6.[15](https://github.com/python/cpython/actions/runs/14786163251/job/41515167379?pr=133278#step:4:16).0...Fri, 02 May 2025 00:38:55 GMT Fetching llvm-19.1.7.0...Fri, 02 May 2025 00:42:13 GMT Finished.

Just to confirm, these lines in the build output mean that it's working, yes? (I think the last one isn't from your script, but it's not an error, so that implies success)

    =============================================================  JIT support for x86_64-pc-windows-msvc is still experimental!             Please report any issues you encounter.             =============================================================    Regenerate cases  Generated sources are up to date

Another possibility is to integrate the LLVM fetch into the script itself, so that we can check whether the files are up to date first and only download LLVM if it's needed (using/ignoring a separate install, as appropriate - I could see this being a case where we'd prefer to ignore it when we don't know which version it is)

Do we need to change 18 to 19 here to unify the build?

Do we need to change 18 to 19 here to unify the build?

Not sure what you mean by "unify the build", but that LLVM version is unrelated. That's for if you want to build all of CPython with LLVM; this change is just for generating the templates the JIT compiler uses, which has stricter version requirements and can be different than the compiler or version used to build the interpreter itself.

Looks great! Though so far, this is the part that makes me sad (watch the timestamps). I guess it's unavoidable though.

Yeah, it's a bummer that it takes a few minutes (maybe we could trim stuff we don't need from the hosted install, but I imagine most of the size is in the parts that we depend on). But if I understand correctly, it should download only once per machine that's doing Windows builds and remain cached, so it's not like Windows JIT core devs' daily build times just went up or anything.

Plus, we don't actually download it unless you're building the JIT, so most people should be unaffected (for now).

Plus, we don't actually download it unless you're building the JIT, so most people should be unaffected (for now).

Ah, yeah, I didn't catch that first time through.

And yeah, it'll be once per machine. I was mostly thinking about CI, which uses a fresh machine each time, and also CI that bypassesbuild.bat (msbuild pcbuild.proj is the typical way, and it's not unreasonable to do it when building releases).

And yeah, it'll be once per machine. I was mostly thinking about CI, which uses a fresh machine each time, and also CI that bypassesbuild.bat (msbuild pcbuild.proj is the typical way, and it's not unreasonable to do it when building releases).

Yeah. For the former we need to install it anyways. For the latter, they'll just need to make sure to set the right options to omit the LLVM install when it's not needed if they want to avoid waiting.

(Another option could be to make the LLVM install default to "false" inget_externals.bat, and havebuild.bat enable it when needed. Not sure if that makes things better, or just more confusing.)