Fix #101873: wmic not found on insider builds of Windows 11 #101874
No reviewers
Labels
No Label
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Information from Developers
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/blender-open-data#101874
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "xavierh/blender-open-data:xavierh-patch-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
wmic is starting to disappear from Windows builds, we can't rely on it anymore.
On Windows 10 and above, we can use powershell instead.
Rather than keeping the cpu_cores Windows implementation separate from the cpu_cores library, as it got bigger, I've moved it inside.
The upstream cpu_cores project is dormant with a last commit 11 years ago and never accepted a PR, so I've added Windows support in-place.
Note I've only verified on my machine - I don't have a dual socket Windows system to verify these changes on.
I am not sure if powershell is available o nWindows 8, and whether it is always guaranteed to be called
powershell
and notpwsh
. Maybe Ray have some better insights. I can't tag him here, perhaps because he is not in the infra team.not a frequent powershell user, but according to wikipedia windows 10 and 11 come with powershell 5.1 out of the box (which uses powershell.exe) so that should be ok.
windows 8.x won't have it though, so we may have to do a
Ah, I didn't picture Windows 8 was still supported.
Rather than testing if wmic exists, checking on windows version directly sounds cleaner/easier to maintain.
I've added a commit to do this and then.. code looked a bit big in this area, I moved it to cpu_cores and then noticed it was an already existing library. I'm not sure if you want to keep the code separate or extend cpu_cores as I did?
The current build instructions didn't fly on my machine (not finding autogen.sh in freetype when building from msys2/mingw64), I've only tested my changes in python outside of the launcher.
Rather than knowing for sure the thing you're about to execute exists feels cleaner than making the assumption it exists based on on a different heuristic? I'm not sure i agree with that, on the other hand, I expect your way to still work just fine
I have been a bit vague on my reasons but I believe I have quite good ones:
The advantage of the solution from Ray is that it minimizes possible side-effects on Windows 10, and Windows 11 prior to this PR. As Xavier said, the solution was not verified on a dual-socket system. So from keeping the change safe, with only potential issues on the newer system, following Ray's advice is much more welcome.
It is also weird to modify vendorized package. Unless you plan to upstream it?
It'd be best if this solution could be verified on a dual-socket system before being adopted: do you know someone with such system, running Windows ?
If not, sure, Ray's solution is better (still crossing fingers a useless wmic.exe will not appear).
It was equally weird to me to implement part of the feature in-place for one OS and not for the others. The upstream project is dormant with a last commit 11 years ago and never accepted a PR. If you prefer the earlier solution, we can just revert last commit.
This whole thing is not a hill to die on for me, either way is fine, the argument about a dummy wmic eventually popping up is a valid concern, so lets just go with what you have now, and if people do end up running into issues we can always improve the heuristics later.
Indeed. If it is verified that'd add confidence to the change.
Unfortunately, no. All the dual-socket systems here run Linux or BSD.
Will ask maybe Lukas Stockner happened to have access to such machine. Or, otherwise, could try doing a quick Windows install on some EOL machine from a storage room.
That is a good point.
Would be good to have explanation somewhere (either commit message, or PR itself). Not sure if you'd prefer the change landing as individual commits or as a squashed commit?
Today I've been able to find a dual socket machine running Windows to validate my changes, they do work as intended.
I'm fine either way. We can go with the quickest, which is to edit the description to summarize the explanations, and land as a squashed commit.
Thanks for tests. We'd need to actually package the script and update the launcher etc, but that's on us and not something that could happen as a PR.
CC @fsiddi to put on the radar.
The new version of the script is now in production, and will run when selecting Blender 4.2.0 (and future versions). Thank you for your contribution! 🎉