32bit compiler error

[sha...@infograph.com]

Windows 64bit compiles and links fine.  But 32bit gives the error:

'C:/Program' is not recognized as an internal or external command,

operable program or batch file.

I looked through toolchain.ninja and there are no cases of program files being used without quotes around it.

Where could this one be coming from?

[sha...@infograph.com]

*taps on microphone*

Bueller?

Bueller?

[Cary Clark]

Try comparing your build with ours to see if you can spot the differences.

You can see our Windows build at http://status.skia.org/repo/skia?filter=search&search_value=build-win

Hover over the white ovals up top to find the one that most closely examines yours, maybe:

Build-Win-Clang-x86-Debug or  Build-Win-MSVC-x86-Release or the like.

From there, click on a green oval to drill down to see our gn and ninja command lines, and the environment variables we've set.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Brian Osman]

Our 32-bit Windows builds are *barely* supported by our GN build environment, and I think you're bumping into that. Unlike other builds, the x86 configuration is only tested using our bundled toolchain. In particular, look for "env_setup" in gn/toolchain/BUILD.gn. Basically, to do the 32-bit build, we run the SetEnv.cmd script from MSVC, which means we invoke all build commands with "cmd /c SetEnv && <command>". As commented there, we don't support local x86 builds - I think the expansion of $win_sdk to get the SetEnv.cmd path is what's failing for you. (In our x86 bot builds, the SDK/toolchain is in a path with no spaces). I'm not sure if there's a safe way to guard that path (might need to escape the spaces?). If all else fails, you can use something like SUBST to get a short (no spaces) path to your SDK folder, then set that in your gn_args:

C:> SUBST W: "C:\Program Files (x86)\Windows Kits\10"

gn gen --args="win_sdk='W:'"

[sha...@infograph.com]

Do you know what download package installs SetEnv.cmd?

It didn't come with VS 2017.

[Brian Osman]

It looks like it's part of the Windows SDK (rather than Visual Studio itself). Although VS should install at least one version of the SDK, I think? Try looking in Program Files (x86)\Windows Kits\10\bin

[Shawn Riordan]

That folder exists, but is empty.

When I search for "windows sdk" in msdn downloads, all the results are about Kinect or phone sdks.  Also, they are all 2015 or older.

[Alexander Vostres]

Here's patch I've used to build m67 some time ago. Also, runtime crashes in x86 builds with OpenGL are fixed (I guess that Chrome only uses ANGLE path so the rest is untested).

[Brian Osman]

As for SetEnv.cmd, you're right. I thought it was still part of the Windows Kits, based on some Chromium documentation, but it looks like it's a fairly old concept. Chrome keeps it going, using a script that collates the contents of the VS toolchain and Windows SDK, and then generates SetEnv.cmd from a python script (https://cs.chromium.org/chromium/tools/depot_tools/win_toolchain/package_from_installed.py?l=237). That bundle is what's used by our bots to do x86. I've attached (renamed to bypass security filters) the copy of SetEnv.cmd that gets generated - it's got loads of relative paths and also assumes the directory layout where the SDK and VisualStudio are side-by-side, but you can at least see which environment variables it's setting.

[Shawn Riordan]

Thanks for that.  Doesn't fix everything, but it helps get me further.