gh-124111: Only set TCLSH_NATIVE for AMD64/ARM64 by zware · Pull Request #149443 · python/cpython
The Tcl 9 makefile.vc now uses TCLSH_NATIVE during the build process,
not just the installation. We had been setting it to the installed
location of the x86 tclsh.exe, which does not yet exist when the x86
build process needs it. That build doesn't actually need TCLSH_NATIVE,
though (there's a check specifically allowing TCLSH to be used if
MACHINE is IX86 and TCLSH_NATIVE is undefined), so don't set it.
The Tcl 9 makefile.vc now uses TCLSH_NATIVE during the build process, not just the installation. We had been setting it to the installed location of the x86 tclsh.exe, which does not yet exist when the x86 build process needs it. That build doesn't actually need TCLSH_NATIVE, though (there's a check specifically allowing TCLSH to be used if MACHINE is IX86 and TCLSH_NATIVE is undefined), so don't set it.
I think this should be enough to allow the tcltk Azure build to actually build 9.0.3.
Enough for the win32 build, but amd64 is still broken. Looking into fixes.
Looking into fixes.
At a glance, it's expecting a packaged ZIP that we're clearly not packaging.
If you can skip the "install" step and just copy out the files we use, that would be an improvement. Only Tix really needed complex install steps, as I recall.
Actually, it's still the tclsh that it's not finding in order to produce the ZIP, due to TclVersion (and things derived from it) still being 8.6.15.0 from tcltk.props, and thus looking for tclsh86t.exe instead of tclsh90.exe. I think our best bet might be to extract TclVersion from TclSourceTag (and likewise TkVersion from TkSourceTag just for good measure) and pass that into msbuild in the tcltk-build.yml workflow, but I'm not sure the best way to go about that.