Building a three-year-old version of Chrome on Windows

[Bruce Dawson]

I decided I wanted to investigate an old Chromium performance regression. Building old versions of Chrome turned out to be trickier than expected and I wanted to share my steps in case they are useful, and in case anybody wants to tell me how I could have done it more easily. And I wanted to point out that we currently can't build old versions of Chrome, and if we care about this (I'm not saying we should) then we need to test for it.

The hash I was trying to sync to is af4e289461794790203de6d050198b7e8e7ad5d1 (July 2016) so first I checked out that hash. I then tried "gclient sync -D" but hit an error. Over time depot_tools has gotten better at finding errors in DEPS files (which is good) and those errors have been fixed, but that causes failures when running gclient sync on an old repo:

  File "c:\src\depot_tools\gclient_eval.py", line 319, in _validate_statement

    target.id, filename, getattr(node, 'lineno', '<unknown>')))

ValueError: invalid assignment: overrides var 'recursedeps' (file 'c:\\src\\chromium4\\src\\DEPS', line 963)

So I checked out an old version of depot_tools (sync to old version, set DEPOT_TOOLS_UPDATE=0) but that hit more intractable problems so I went back to the latest version of depot_tools and patched recursedeps in the DEPS file to use the current value.

That eventually caused other problems when the "gclient runhooks" phase tried to run the file build\gyp_angle:

c:\src\depot_tools\.cipd_bin\vpython.exe: could not resolve options: failed to resolve Python script: CreateFile c:\src\chromium4\build\gyp_angle: The system cannot find the path specified.

Error: Command 'vpython.bat build/gyp_angle' returned non-zero exit status 1 in c:\src\chromium4

Apparently the recursedeps paths went from being DEPS-file-relative to src-directory-relative. I commented out the problematic line and that seemed to be sufficient.  

I then hit this error in build/gyp_chromium.py:

    x64_runtime, x86_runtime = vs2013_runtime_dll_dirs

ValueError: too many values to unpack

I recognized that issue as being caused by the addition of a third-runtime on Windows - we now support x64, x86, and arm64. A dictionary for the return value would have been more stable but it's a bit late for that. I patched this by adding an extra variable to grab the third return value.

I then hit problems with gen_file_type_proto.py not being able to find optparse:

  File "browser/resources/safe_browsing/gen_file_type_proto.py", line 21, in <module>

    import optparse

ImportError: No module named optparse

I assume that this is something to do with vpython and wheels but I resolved this by hacking the script to add depot_tools\bootstrap-3_8_0_chromium_8_bin\python\bin\lib to sys.path.

With that I was able to build chrome in out\release and it ran!

I then wanted to share my must-never-be-submitted modifications to ancient Chrome by uploading a CL. ExecPresubmitScript failed with this error:

  File "c:\src\depot_tools\presubmit_support.py", line 1335, in ExecPresubmitScript

    return post_upload_hook(cl, change, OutputApi(False))

  File "PRESUBMIT.py", line 103, in PostUploadHook

    (

AttributeError: 'Changelist' object has no attribute 'RpcServer'

I tried with --bypass-hooks but that didn't help, so I changed the "return post_upload_hook" to just "return {}"

The final result is https://crrev.com/c/1987293 and if I get a chance I'll investigate the old performance regression.

P.S.

I have heard complaints that "git cl upload" runs slowly if you are too far behind head. I think that 3.5 years counts as a torture-test of this theory and I found the "git cl upload" performance quite reasonable - has that issue been fixed?

[Andy Perelson]

There have been huge improvements, but there's room for it to get even better. The short version is that there is no negotiation as part of push, and in some cases git push in git cl upload was sending up huge amount of unnecessary information to the server, which then spent time getting processed before largely being unused. We've made some tweaks to ref advertisement to make it more likely that your git client sees a ref that helps it upload less, though not a minimal amount. Eventually we'll get a protocol v2 for push, which will include some amount of negotiation, and this can improve even more. But it's always going to be a bit of a trade off of more negotiation to send less bytes and you could go too far in that direction too.

 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAE5mQiMLWxphqSswOL2Cu38E63s3iUn63-RftkK6yoWXMk2EJw%40mail.gmail.com.

[Marshall Greenblatt]

Checking out depot_tools to a commit (based on date) that matches the desired Chromium version can help, but repository paths may still have changed, or the required buildtools binary versions (clang-format, gn, etc) may have been deleted from gsutil storage. You might have better success downloading a tarball at the desired version from https://gsdview.appspot.com/chromium-browser-official/. You can then manually install the required Visual Studio and Windows SDK versions and set DEPOT_TOOLS_WIN_TOOLCHAIN=0. I've been tracking the required tools versions for older branches here if you need a reference.