Building Skia on Windows 32 bit - skia

Question

I'm building Skia on Windows following this link.
For Windows x64 the build was quite smooth. But not for 32 bit.
1) I tried specifying target_cpu = "x86" instead of target_cpu = "x64", gn gen works fine but ninja throws errors complaining that the paths to visual studio contain spaces. It has all sorts of errors similar to the following:
"C:\Programs " is not a valid path.
2) I tried generating sln files and building from within IDE (which is an alternative as mentioned in the link). However, I can't even get the x64 version to compile this way (a lot of non-zero exit codes from ninja, no further messages observed).
3) I tried using the toolchain that the website claims to be "the only way to support 32 bit builds". The toolchain is to be downloaded using the following command (to be executed in skia dir):
python infra/bots/assets/win_toolchain/download.py -t C:/toolchain
I managed to work around loads of intricacies (gutil conflicts, .py extension omissions, path variables, to google cloud service) and I'm now stuck at this:
Logged in as xxxxxxxxxxxxxxxx
AccessDeniedException: 403 Caller does not have storage.objects.list access to bucket skia-buildbots.
I'm not restricted to the way it is built so long as it generates the "libs" for me. But with a large project having so many external dependencies I don't think it's easy to brew my own way.

Answer 1

One solution I've found:
Open the out\Release\toolchain.ninja text file (or the toolchain.ninja specific to your configuration)
Remove the following string (you can use a "Replace Text" with an empty string in your text editor):
C:/Program Files (x86)/Microsoft Visual Studio 14.0/win_sdk/bin/SetEnv.cmd /x86 && C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64_x86/
from everywhere (in case that you've used the x86, for x64 the string might be different)
And use ninja -C out/Release dm as usual
In this way we are using a toolchain where cl.exe, ml.exe link.exe commands are called directly (accesible from the PATH environment)

Answer 2

An other solution base on #dacap's. But I edit the gn configure instead.
Change file gn/toolchain/BUILD.gn
...
if (msvc == 2015) {
bin = "$win_vc/bin/amd64"
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
if (target_cpu == "x86") {
# Toolchain asset includes a script that configures for x86 building.
# We don't support x86 builds with local MSVC installations.
env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
}
...
To
...
if (msvc == 2015) {
if (target_cpu == "x86") {
bin = "$win_vc/bin"
} else {
bin = "$win_vc/bin/amd64"
}
} else {
bin = "$win_vc/Tools/MSVC/$win_toolchain_version/bin/HostX64/$target_cpu"
}
env_setup = ""
#if (target_cpu == "x86") {
# # Toolchain asset includes a script that configures for x86 building.
# # We don't support x86 builds with local MSVC installations.
# env_setup = "cmd /c $win_sdk/bin/SetEnv.cmd /x86 && "
#}
.....

Answer 3

It seems that (as of skia m67) #WinCloud's fix is partially merged to upstream (still has to remove env_setup part though).
However, as noted in comments - it will crash during OpenGL initialization.
I've fixed all that (at least to the point where demo apps are runnable), as a little extra - fixed .lib compatibility with Visual Studio's Debug configurations.
Included are .bat files that build "no system libs" configuration with Clang (as the readme explicitly states that VC++ builds may have performance issues). To use those just download latest LLVM from https://releases.llvm.org/download.html and install it into default location (tested with 6.0.0).
If you need DLL runtime linking you'll have to edit gn/BUILD.gn file - add /MD flag by default and change /MTd to /MDd for debug.
Here's patch based on chrome/m67 branch:
https://gist.github.com/Alexx999/39eae9182eecaa3dc06e73fdb3a1e7d9