There is a problem with Windows build. To be more precise with the gclient.
When it's run on Windows among other scripts it executes cipd.bat which tries to use PowerShell and fails:

'powershell' is not recognized as an internal or external command,
operable program or batch file.

@kevinsawicki, since you are the person who added gclient in #309,
could you please take a look?

could you please take a look?

Taking a look now

@alexeykuzmin Windows builds should be compiling now, there was an issue with the PATH on the CI workers and powershell was not available from it, fixed now.

I also updated the depot_tools submodule to latest just to pull in any other gclient fixes that may be in there.

@kevinsawicki, I see "Permission denied" errors at the very end of win builds now: http://208.52.191.140:8080/job/libcc-win-ia32/155/console

I see "Permission denied" errors at the very end of win builds now: http://208.52.191.140:8080/job/libcc-win-ia32/155/console

Weird, I've seen this once before but it seemed to pass the next time the build ran, don't see anything very helpful in the google results for it.

The only problem left in static_library build on Windows is:

LINK(DLL) events.dll events.dll.lib events.dll.pdb
FAILED: events.dll events.dll.lib events.dll.pdb
D:/libcc/vendor/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /IMPLIB:./events.dll.lib /DLL /OUT:./events.dll /PDB:./events.dll.pdb @./events.dll.rsp
event.obj : warning LNK4217: locally defined symbol ??0LatencyInfo@ui@@QEAA@XZ (public: __cdecl ui::LatencyInfo::LatencyInfo(void)) imported in function "protected: __cdecl ui::Event::Event(struct tagMSG const &,enum ui::EventType,int)" (??0Event@ui@@IEAA@AEBUtagMSG@@W4EventType@1@H@Z)
LINK : error LNK1218: warning treated as error; no output file generated

The latest changes in Chromium related to LatencyInfo were made in CL 2783973002. Related changes in this PR are 2140ff4 and ec6f131.
Any thoughts? @kevinsawicki @zcbenz

@alexeykuzmin Have you tried changing latency from source_set to component?

Have you tried changing latency from source_set to component?

@zcbenz It looks like it helped. Thanks!

Links to all the builds lead to 404 error pages. Is it ok?

@alexeykuzmin I'm not sure what happened, those links work fine on my side, the CI is failing for failing to apply patches:

warning: squelched 55 whitespace errors
warning: 60 lines add whitespace errors.
C:\e\workspace\libcc-win-ia32\patches\latency_info.patch:6: trailing whitespace.

C:\e\workspace\libcc-win-ia32\patches\latency_info.patch:7: trailing whitespace.
import("//testing/test.gni")
C:\e\workspace\libcc-win-ia32\patches\latency_info.patch:8: trailing whitespace.

C:\e\workspace\libcc-win-ia32\patches\latency_info.patch:10: trailing whitespace.
component("latency") {
C:\e\workspace\libcc-win-ia32\patches\latency_info.patch:11: trailing whitespace.
  sources = [
error: git apply: bad git-diff - expected /dev/null on line 72
latency_info.patch failed to apply
Error executing command ` python .\script\cibuild `.

I'll reset the workspace and restart the build.

And there are lots of warnings because of lines like this, which has a trailing space after +:

+ 

@zcbenz

error: git apply: bad git-diff - expected /dev/null on line 72
latency_info.patch failed to apply

I'm pretty sure it's caused by line-endings in a patch file being converted to "CRLF" on checkout. Do we set core.autocrlf false in global git config on Windows build machines?

And there are lots of warnings because of lines like this, which has a trailing space after +

I have also seen those warnings on my Windows machine, but they seem to be harmless.

@kevinsawicki, trailing space should be there, right? For example you have added some here: 6a905a1.

@zcbenz

I'm not sure what happened, those links work fine on my side

For example libcc-win-ia32 leads to http://208.52.191.140:8080/job/libcc-win-ia32/166/ and the response is:

HTTP ERROR 404

Problem accessing /job/libcc-win-ia32/166/. Reason:

    Not Found
Powered by Jetty://

I have also seen those warnings on my Windows machine, but they seem to be harmless.

Yeah, these are just git apply warnings and can be ignored, they only appear on windows.

error: git apply: bad git-diff - expected /dev/null on line 72
latency_info.patch failed to apply

I'm pretty sure it's caused by line-endings in a patch file being converted to "CRLF" on checkout. Do we set core.autocrlf false in global git config on Windows build machines?

@kevinsawicki @zcbenz
In the repo "latency_info.patch" has LF line-endings. On my Windows machine git wasn't configured properly and I had exactly the same error, changing line-endings to LF fixed it.
Can we run git config --global core.autocrlf false on Windows build bots before checkout?

libchromiumcontent-osx build:

error: ui/latency/ui_latency_export.h: already exists in working directory
latency_info.patch failed to apply

It looks like the workspace was not cleared before the build and "ui/latency/ui_latency_export.h" was left in the Chromium tree from the previous build. Maybe it would make sense to remove all untracked files before applying patches?

@kevinsawicki It seems that we have to upgrade our CI machine to newer Linux distributions now.

Currently cross compilation is broken because the clang binary now links the targets with libstdc++ that is newer than the one installed on our CI machines, so indeterminate executables (like mksnapshot) are no longer able to run on the CI machines, resulting in build failures.

I have tried to revert to an old version of clang that works, but the build can not pass even with some hacks (9296aa9, 043faa2, d6dd947), some build configurations are assuming the version of clang.

Another choice is to build with gcc instead of clang, but I don't think we should do it.

@alexeykuzmin I pushed a few commits trying to fix the patching, I don't know whether it works though because the Windows CI is down for now.

@zcbenz, @jkleinsc
Can someone please run Linux builds?
I had to make a rebase to fix merge conflicts after merging #344.

@alexeykuzmin builds are on their way