msbuild call failure with 'flutter run' on Windows

[stuartmorgan]

Splitting out from google/flutter-desktop-embedding#342 (comment)

Summarizing the error:

Build process failed

#0      throwToolExit (package:flutter_tools/src/base/common.dart:24:3)
#1      buildWindows (package:flutter_tools/src/windows/build_windows.dart:56:5)
[...]
[  +13 ms] 'C:\Program' is not recognized as an internal or external command,
[   +3 ms] operable program or batch file.

That looks very much like the vcvars64 path was split on spaces. What doesn't make sense about that is that this path pretty much always has spaces, so I don't understand why this would happen to someone else, but not be reproducible for me.

I'll make a branch tomorrow with some additional logging to make sure that's indeed what's happening (and not a strange issue with finding the vcvars64.bat path, for instance). Meanwhile, @contrix09 is there anything unusual about your CMD.exe configuration (e.g., something that might cause paths to be processed an extra time)?

[contrix09]

@stuartmorgan not that I'm aware of.

[stuartmorgan]

I've set up a branch for debugging this. As a starting point, it just adds some logging to make sure I understand where the problem is; if you flutter run with that branch, what is printed starting with ### Running? (Feel free to obfuscate the path to Runner.vcxproj if you like, since that shouldn't be relevant.)

[contrix09]

Hi. How can I use your updated flutter_tools. It seems that running flutter run on your branch uses my currently installed flutter sdk. I can't see any output from flutter run starting with ### Running.

[stuartmorgan]

Sorry, I thought checking out a different branch would be enough to trigger a rebuild, but it sounds like that's not the case. You can delete bin/cache/flutter_tools.* to force a rebuild.

[contrix09]

Here is the output:

### Running [C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat, &&, msbuild, PATH/TO/Runner.vcxproj, /p:Configuration=Release]

[stuartmorgan]

Okay, so that rules out something weird happening with locating vcvars64.bat in the first place.

Can you try updating that branch and then running again? I've added quoting to the path; this breaks the build for me, but if it works for you that would be more evidence that it's being double-interpreted somehow. (If that's the case, maybe we'll need to think about generating a batch script that does the two steps, rather that passing through the shell, unless we can figure out why behavior is different.)

It would also be helpful if you could try running C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat manually in a command prompt to make sure that it works for you in general (i.e., that the error isn't actually from within that script on your machine, rather than in trying to run it).

[contrix09]

Here's the output from your latest changes:

### Running ["C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat", &&, msbuild, PATH\TO\Runner.vcxproj, /p:Configuration=Release]
[...]
[  +13 ms] The filename, directory name, or volume label syntax is incorrect.

When I try to run the full path of vcvars64.bat:

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

[stuartmorgan]

When I try to run the full path of vcvars64.bat:

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

That's when properly quoted for invoking it in the shell manually? I.e., the script is successfully invoked, but is logging that error internally?

[contrix09]

No, it was not quoted. But when quoted, i.e. "..\vcvars64.bat", it runs.

[stuartmorgan]

So it's not from within the script then. I'm perplexed as to how invoking it could fail both when quoted and when not quoted. (And why so far this is specific to your environment.)

I think the next step is to try having the build process write a temporary .bat file that invokes (quoted) vcvars64.bat then runs the build. Without knowing what the cause of the problem is though, it's hard to guess whether that will fix it. It would let us avoid passing the invocation through shell interpretation though, which would eliminate a possible source of issues.

[SilentPenguin]

Ok, I have had two issues wrt building on windows. Both of them are path related, of which this issue was one. I've managed to isolate their causes on my system.

The error discussed here is thrown when there's a space in the path to the example project. My username contains a space and I checked out the example desktop repo into my documents folder. Moving the repo to C:\src without a space resolves that issue and presents a second.

The second error reported is the input line is too long, the syntax of the command is incorrect. I found the only way I have been able to successfully build the example repo is by ensuring my git repo is checked out at the root of my drive.

Yeah, the error is absolutely bananas for what is going wrong, but hope this helps you to reproduce the issues your side.

[stuartmorgan]

The error discussed here is thrown when there's a space in the path to the example project.

Interesting, the form of the error made it seem like the issue must be with the command rather than the project path. Thanks for tracking that down.

It seems like the easiest solution to both of these issues is to add a bat file as discussed above. We can design it so that it's intended to be run with the working directory set to the <project>/windows directory, so that the msbuild line can just use the project name instead of a full path. In that setup the vcvars64.bat invocation will be a separate line, so no individual command should be very long.

[stuartmorgan]

https://github.com/stuartmorgan/flutter/tree/msbuild-bat-wrapper has the first pass at a fix. I don't have a Windows machine at the moment so it was written on macOS, which means it's never actually been tested; there may well be typo in vs_build.bat.

I'll actually test it next week and get it landed, but you're welcome to try it out now and see if it works for you.

[SilentPenguin]

Happy to be of help.

I've been able to test this. My copy of your branch is located at C:\src\flutter.copy and my desktop example project is located at C:\Users\<username>\Documents\Code. My username contains 12 ASCII characters, one of which is a space.

While testing, I discovered one issue. The path join in build_windows.dart#L32 fails to create the correct path to the vs_build.bat. This line should read fs.path.join(Cache.flutterRoot, 'packages', 'flutter_tools', 'bin', 'vs_build.bat') instead.

After that line was changed, calling C:\src\flutter.copy\bin\flutter run from the desktop example directory still fails to build correctly with the less than descriptive error build process failed. I did copy git repo locally to skip re-downloading everything, but I deleted the flutter_tools snapshot and stamp from the cache, so that shouldn't be the reason. I'll let you test yourself first before I dig any deeper, since I've not been able to track down a cause.

Let me know what your findings are when you have the chance to test.

[stuartmorgan]

The path join in build_windows.dart#L32 fails to create the correct path to the vs_build.bat.

The hazards of writing a patch on a machine where I can't actually run it! Fix pushed to the branch.

fails to build correctly with the less than descriptive error build process failed.

That's just the Flutter tool output when the script returns non-zero; the actual error that caused it should be somewhere earlier in the output if you use -v. (Error display in non-verbose mode for Windows build hasn't been tuned at all.)

[stuartmorgan]

The remaining problem with spaces is in the FDE example project rather than the Flutter tooling.

[SilentPenguin]

My mistake, I didn't scroll far enough to find the error, previously the error was in the line above build process failed. I suspected the remaining issue was outside the build path since I was able to run the commands the bat file was trying to run, with errors.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.