Support local mirrors for all downloads (Git, files, etc) when building CEF/Chromium

Issue #1728 resolved
Adam Gross created an issue is hardcoded to try to use python.bat and git.bat from depot_tools (ref: ) but AFAICT those scripts are not available anymore on the depot_tools master branch (ref: ). We need to come up with a different mechanism for using git and python or just start requiring that developers have git and python in their %PATH%.

Comments (17)

  1. Marshall Greenblatt

    The bat files are created by depot_tools on first run. See depot_tools/bootstrap/win/win_tools.bat. What command-line arguments are you passing to

  2. Adam Gross reporter

    Unfortunately my company has rules where the official build servers are not allowed to access external resources; we need our builds to be reproducible some day in the future and if we are depending on external git repositories, there is always the chance that they could go down or be moved. As a result, we have internal mirrors of cef.git, chromium_depot_tools.git, and chromium_src.git.

    Currently I am playing with two different approaches, each with their own pitfalls:

    1) Use "git submodule" semantics to clone the 3 git repositories into subdirectories of a specific folder, using the subdirectory naming conventions expected by Then I run with command-line params: --download-dir=%SRCROOT% --no-update --depot-tools-dir=%SRCROOT%\depot_tools --url=<internal_cef_mirror> --branch=2454

    Even if I extract some .zip files manually to get git.bat and python.bat, I still seem to be missing supplemental python scripts such as As a result, I end up with an error like what is attached in error.txt. It sounds like from your previous comment, running win_tools.bat would be a prerequisite to calling and that would be fine; that file doesn't seem to have any hardcoded external paths in it like many other files do. I'm not sure if I will get much farther though.

    2) Use "git submodule" semantics to clone cef.git and chromium_depot_tools.git (although the latter isn't 100% necessary). Then I would set the DEPOT_TOOLS_UPDATE environment variable flag to 0 and run with command-line params: --download-dir=%SRCROOT% --no-cef-update --no-depot-tools-update --depot-tools-dir=%SRCROOT%\depot_tools --url=<internal_cef_mirror> --chromium-url=<internal_chromium_mirror> --branch=2454

    Note that this command uses some additions to the script to disable updating only depot tools and cef and overriding the Chromium git repository URL.

    In this case, I don't sync cef because it's a submodule; this is important because this means that new official builds that only have a cef hash bump will actually have a new overall hash. I also need to prevent updates of depot tools because update_depot_tools scripts have an external URL hardcoded.

  3. Marshall Greenblatt

    Generally speaking depot_tools doesn't need to be updated as frequently as it currently does by default. Usually you're pretty safe if you update it once per release branch (for example, update it immediately before building a new release branch for the first time). You could do the following:

    1. Download depot_tools using Git on your local Windows machine.
    2. Run update_depot_tools to download the necessary dependency sub-directories (python, git, etc) and create the bat files.
    3. Zip up the resulting depot_tools directory and put it somewhere that your build system can access.
    5. Run with --depot-tools-archive=<path_to_zip>

    Having an internal mirror of cef.git is easy, you can currently specify the URL via the --url command-line flag.

    Having an internal mirror of the various chromium Git repos is reasonably strait-forward if you rewrite the .gclient and src/DEPS files.

    However, there are still many downloads performed by Chromium's gclient runhooks step (see the hooks section of src/DEPS). Are you planning to rewrite all of those scripts as well?

  4. Marshall Greenblatt

    Having an internal mirror of the various chromium Git repos is reasonably strait-forward if you rewrite the .gclient and src/DEPS files.

    Note that currently supports a mechanism for patching Chromium's DEPS file: just create a patch/patches/DEPS.patch file and check it into your CEF repo. Then you'd need to:

    1. Add support in for a --chromium-url flag to customize the .gclient file or just write the .gclient file yourself.
    2. Keep the DEPS.patch file up-to-date with changes to the source Chromium DEPS file.
  5. Adam Gross reporter

    Thanks for all of the direction; I really appreciate it. Yeah I will definitely overwrite the part of that writes the Chromium URL into .gclient. Past that I agree that adding patches to "patch/patches" should work well.

    The main thing that I'm trying to figure out is which of the various DEPS files I need to patch. If I search the Chromium source for "", "", and "", I see scattered mentions throughout the code, particularly in what appears to be test-specific code. Various files I have found (not an exhaustive list):

    Several scripts in src\media\tools\layout_tests

    Are most of these unused during builds? Or is what I'm trying an exercise in futility?

  6. Marshall Greenblatt

    The main thing that I'm trying to figure out is which of the various DEPS files I need to patch.

    You should only need to worry about the scripts run by the hooks section of the top-level src/DEPS file. In current master this includes:

    • src/build/ -- disable by setting GYP_DEFINES=disable_nacl=1
    • src/build/ -- only used on Android
    • src/build/linux/sysroot_scripts/ -- only used for official Google Chrome builds
    • src/build/ -- disable by setting DEPOT_TOOLS_WIN_TOOLCHAIN=0
    • src/third_party/binutils/ -- uses download_from_google_storage on Linux
    • src/tools/clang/scripts/ -- uses urllib2 directly
    • src/build/ -- uses urllib2 via depot_tools/
    • src/third_party/instrumented_libraries/scripts/ -- disabled by default
    • depot_tools/ -- uses urllib2 via depot_tools/

    So it looks like there are 2 scripts responsible for performing all of the downloads, and both scripts use urllib2:

    You could either modify these scripts or perhaps set up a local urllib2 proxy (configured via environment variables) that intercepts the download requests.

  7. Adam Gross reporter

    I am getting pretty far in the process and am hoping to submit a few changes to the active branches (master and 2526?). I have attached a patch (script_changes.diff) that contains my recent changes but am not sure how best to send it out for review; the patch is relative to branch 2526. I also apologize that the patch contains a combination of different changes rolled into one diff. The changes are:

    1. Changes cmake requirement from to That happens to be what we have internally and it has worked well for me. Please let me know if there are any extra factors that specifically required
    2. New command-line arguments:
      • --chromium-url: Allows overriding the synced Chromium URL
      • --no-cef-update: Allows bypassing the step to sync cef. Internally we use it as a git submodule for build reproducibility.
      • --no-depot-tools-update: Allows bypassing the step to update depot_tools. Again we use this as a git submodule for build reproducibility.
      • --distrib-subdir: Allows specifying the subdirectory name of chromium/src/cef/binary_distrib. Currently creates a very specific directory name that is difficult for our scripts to parse and I wanted to bypass this.
    3. Support in for --distrib-subdir.

    That last "--distrib-subdir" is one that I want to explain a bit more because I'm not sure I'm doing it the best way. The problem is that right now the scripts create a subdirectory named, for example on branch 2454, "cef_binary_3.2454.0.gUnknown_windows32". Our build then needs to extract that folder to a staging directory that is consumed by other components. I have found that my scripts are a lot easier to understand if I override that subdir name to something more static, like "cef-package".

    This works for us because we only build either debug or release builds and only x86, so there is no conflict between multiple folders. But I am wondering if it would be better if I just add a simpler command-line arg like "--use-basic-distribdir-name". In this case can do something like "cef-package-[debug,release]-[x86,x64]". This would still work for our purposes but would make it more future-proof if building multiple configurations.

  8. Techwolf Lupindo

    I second and voted for this issue. I'me just starting out looking at doing a from source build on a non-debian system. The problem I saw right off the bat was these automated build scripts download a ton of stuff into the local sandboxed build and that sandbox is deleted with every rebuild done by the distro build and packaging system. Meaning for each rebuild I do, that ton of stuff is re-download every time, adding hours for each local fix and re-test. Being able to seperly download all the depends and point the automated build scripts to the local "mirror"(that consist of local files, not a server) would help here greatly.

  9. Marshall Greenblatt

    @grossag : Please submit a pull request against the current master branch with your changes.

    Changes cmake requirement from to

    What changed between these versions?

    New command-line arguments

    These all sound OK. We should probably add separate --no-cef-update, --no-chromium-update and --no-depot-tools-update flags, and have the existing --no-update flag just turn on all of the --no-*-update flags.

    I am wondering if it would be better if I just add a simpler command-line arg like "--use-basic-distribdir-name". In this case can do something like "cef-package-[debug,release]-[x86,x64]".

    No, I think the version that you initially propose (completely user-specified folder name) is better. The caller of knows what they're requesting so they can append the platform or other information themselves if they choose.

  10. Adam Gross reporter

    I think we are close to having this resolved on the Cef side and maybe even finished. I'm going to leave this issue open for a little while longer but I believe that the rest of the work is on my side in implementing a urllib2 proxy as Marshall mentioned. If others want more info on how I set up my build project and what commands I pass to, let me know.

  11. Log in to comment