[native_toolchain_c] Fix/windows program files spaces#3323
[native_toolchain_c] Fix/windows program files spaces#3323JoshuaR457 wants to merge 9 commits intodart-lang:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
| ## 0.18.1 | ||
| - Remove `runInShell: Platform.isWindows && workingDirectory != null`. Modern | ||
| Dart supports `workingDirectory` on Windows natively without needing a shell | ||
| wrapper, so this workaround is no longer needed. Removing it means `cl.exe` |
There was a problem hiding this comment.
Do you have a reference to a PR that fixed that issue? (I don't remember why I added this, but I did add this because something failed on Windows.)
There was a problem hiding this comment.
I don't have a specific PR reference for when workingDirectory support was added for Windows without runInShell. If you added it originally because something failed, it may be safer to keep runInShell as-is and instead focus the fix on quoting the executable path when runInShell is true.
Would you prefer I take that approach instead?
There was a problem hiding this comment.
I think the first copy of that code I added in https://dart-review.googlesource.com/c/sdk/+/300203/19/pkg/native_assets_builder/lib/src/utils/run_process.dart but I can't find the reason why. I just remember things broke without it.
it may be safer to keep runInShell as-is and instead focus the fix on quoting the executable path when runInShell is true.
Agreed. Let's try if that works.
There was a problem hiding this comment.
Done! I've reverted the runInShell change and instead quote the executable path when it contains spaces and runInShell is true on Windows. This prevents cmd.exe from splitting the path on spaces (e.g. C:\Program Files (x86)\...).
| workingDirectory: workingDirectory?.toFilePath(), | ||
| environment: environment, | ||
| runInShell: Platform.isWindows && workingDirectory != null, | ||
| runInShell: false, |
There was a problem hiding this comment.
We need an integration test that exercises this. Can you add a test that fails without the fix?
There was a problem hiding this comment.
I've updated the tests to use an executable that lives in a path containing spaces. Without the fix (runInShell: true), cmd.exe fails to find the executable. With the fix (runInShell: false), Process.start passes the path directly and it works correctly.
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
PR HealthChangelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with Breaking changes ✔️
This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with |
| final stderrBuffer = StringBuffer(); | ||
| final executablePath = executable.toFilePath(); | ||
| // When running in shell on Windows, cmd.exe splits unquoted paths on spaces. | ||
| // Quote the executable path if it contains spaces to prevent this. |
There was a problem hiding this comment.
maybe make a final runInShell =
and then final executable = runInShell && executablePath.contains(' ') ? ...
There was a problem hiding this comment.
Refactored as recommended. Also looked into the CI failure, I think I got the issue but please don't qute me on that.
| import 'package:native_toolchain_c/src/utils/run_process.dart'; | ||
| import 'package:test/test.dart'; | ||
|
|
||
| export 'package:native_toolchain_c/src/utils/run_process.dart'; |
There was a problem hiding this comment.
What does this export do here?
There was a problem hiding this comment.
Hey, to be honest I'm not to sure. I tried to fix the CI but didn't really understand it, Claude told me this was the fix. Sorry! I'm happy to reverse it though if you want to look into it.
The fix for the original issue however should be correct.
There was a problem hiding this comment.
You should query the AI to understand why. Good AI practices is that you understand the code that you're sending out for review. (I also write almost all of my code with AI, this wonderful new reality. 😄)
There was a problem hiding this comment.
I did and i believe I got it now. Unfortunately one of the steps to get the workflow to not fail, was formatting the files. If this isn't what you want feel free to revert it.
There was a problem hiding this comment.
Yeah formatting 👍 Edit: Make sure you're on the last version of the Dart/Flutter SDK. Because it looks like the formatting is undoing some formatting that I saw a couple of weeks ago.
|
The PR also needs a rebase due to merge conflict. |
d8ec02c to
203ec15
Compare
Description
Building a Flutter Windows app fails when Visual Studio Build Tools is installed in the default path (
C:\Program Files (x86)\...) becauserunInShell: truecauses cmd.exe to parse the executable path, splitting on the space in "Program Files" and trying to executeC:\Programas a command.Fix
runInShell: Platform.isWindows && workingDirectory != null. Modern Dart supportsworkingDirectoryon Windows natively without needing a shell wrapper, so this workaround is no longer needed. Removing it meanscl.exeis invoked directly, bypassing cmd.exe path parsing entirely.commandStringlog string so the logged command is accurate and reproducible.Related Issues
Fixes #3321.
Fixes #2848.
PR Checklist
dart tool/ci.dart --alllocally and resolved all issues identified. This ensures the PR is formatted, has no lint errors, and ran all code generators. This applies to the packages part of the toplevelpubspec.yamlworkspace.CHANGELOG.mdfor the relevant packages. (Not needed for small changes such as doc typos).