electron 的depot_tools 工具下載下傳建構源碼 nodejs寫的
electron 的depot_tools 工具下載下傳建構源碼。這個工具是用nodejs寫的，封裝了chromium自身的depot_tools工具。非常友善易用。
主要是electron在下載下傳完chromium源碼後會打自己的patch。如果用chromium的gclient下載下傳會麻煩，報patch conflicts。這個electron自己用nodejs寫的工具就不會了。
參考自：https://github.com/electron/build-tools
1，預先安裝：
git必須2.2版本以上。
1， 安裝nodejs
如若報錯，須運作如下，解決nodejs缺失很多包：
3，安裝python
sudo apt install python
1，可以用chocolate或者scoop安裝。安裝方法在 ：https://classic.yarnpkg.com/en/docs/install/
安裝chocolate
2，
choco必須在cmd裡面運作：
安裝 git，python，nodejs，yarn(linux下用)或者npm。
（git需要git.exe在路徑上，而不是google的depot tools裡面的git.bat。那樣python就不能運作git了，需要加上shell=ture）
需要安裝glibc編譯庫在linux。如果報錯：
報錯：确實bzip2：
yum search bzip2
yum install bzip2.x86_64
windows上需要安裝vs 2019.
2, 源碼下載下傳并且編譯建構
e init --root=~/electron
不建構的話，分三步走：
View Code
示例：
報錯下載下傳連結找不到pywin32
用這個連結下載下傳解決：https://github.com/mhammond/pywin32/releases/tag/b228。64位用pywin32-228.win-amd64-py3.8.exe。
2、e sync
e sync -vvvv --revision 11-x-y
gclient參數同樣可以加入
-v 或者 -vvvv輸出更多資訊。
e build [target] -v
e build --gen 強制做gn操作，重新生成ninja項目
<col>
Target
Description
breakpad
Builds the breakpad <code>dump_syms</code> binary
chromedriver
Builds the <code>chromedriver</code> binary
electron
Builds the Electron binary (Default)
electron:dist
Builds the Electron binary and generates a dist zip file
打包。可以在e-build.js中加入自動删除zip檔案和移除調試資訊，縮減dist包到100m：
mksnapshot
Builds the <code>mksnapshot</code> binary
node:headers
Builds the node headers <code>.tar.gz</code> file
chromium 編譯報錯 You must installWindows 10 SDK version 10.0.19041.0 including the "Debugging Tools for Windows" feature.
如果已經安裝了sdk，按下圖修改：
nvm
e
nvm ls
e show configs
顯示配置Show the available configurations
nvm current
e show current
顯示版本Show which configuration is currently in use
nvm use <name>
e use <name>
切換分支Change which configuration is currently in use
After you've built Electron, it's time to use it!
Command
e start
Run the Electron build
e node
Run the Electron build as Node
e debug
Run the Electron build in a debugger
e test
Run Electron's spec runner
As usual, any extra args are passed along to the executable. For example, <code>e node --version</code> will print out Electron's node version.
Runs your local Electron build inside of lldb or gdb.
-g webRequest
Starts the local Electron build's test runner. Any extra args are passed along to the runner.
Possible extra arguments to pass:
<code>--node</code> - Run Node.js' own tests with Electron in <code>RUN_AS_NODE</code> mode.
<code>--runners=<main|remote|native></code> - The set of tests to run, can be either <code>main</code>, <code>remote</code>, or <code>native</code>.
<code>e show</code> shows information about the current build config.
The name of the active build config
Lists all build configs
e show env
Show environment variables injected by the active build config
e show exe
The path of the built Electron executable
e show root
The path of the root directory from <code>e init --root</code>.
e show src [name]
The path of the named (default: electron) source dir
e show stats
Build statistics
Example usage:
Opens the GitHub page for the specified commit, pull request, or issue.
For example, <code>e open 0920d01</code> will find the commit with an abbreviated sha1 of <code>0920d01</code>, see that it's associated with pull request #23450, and open https://github.com/electron/electron/pull/23450 in your browser. Since you can pass in a pull request or issue number as well, <code>e open 23450</code> would have the same effect.
Exports patches to the desired patch folder in Electron source tree.
Valid patch directories can include:
<code>node</code>
<code>v8</code>
<code>boringssl</code>
<code>chromium</code>
<code>perfetto</code>
<code>icu</code>
Source Directory
Patch Directory
e patches node
<code>src/third_party/electron_node</code>
<code>src/electron/patches/node</code>
e patches chromium
<code>src</code>
<code>src/electron/patches/chromium</code>
e patches boringssl
<code>src/third_party/boringssl/src</code>
<code>src/electron/patches/boringssl</code>
e patches v8
<code>src/v8</code>
<code>src/electron/patches/v8</code>
e patches perfetto
<code>src/third_party/perfetto</code>
<code>src/electron/patches/perfetto</code>
e patches icu
<code>src/third_party/icu</code>
<code>src/electron/patches/icu</code>
If you want your shell sessions to each have different active configs, try this in your <code>~/.profile</code> or <code>~/.zshrc</code> or <code>~/.bashrc</code>:
This will create per-shell temporary files in which he active config file can be changed with <code>e use</code>.
需要裝nodejs對應版本的pywin32
Electron 打包執行
electron_dist_zip.runtime_deps
添加sscache，加快以後編譯速度：
取回源碼檔案和git cache檔案（.git_cache）裡面的。
以electron為例：
源碼和.git_cache目錄放好後，什麼也别動，先做第一步：（否則總報錯：error: object directory /root/.git_cache/chromium.googlesource.com-chromium-src/objects does not exist; check .git/objects/info/alternates）
1，修改src/electron/.git/objects/info/alternates檔案，指向本地存放路徑。
2,如不想拷貝整個cache目錄，至少需要上面那個目錄下的pack底下的檔案：
這個方案應該更好，以chromium為例：
直接将拷貝回的源碼，用git看會是detached遊離狀态，因為是checkout的一個送出點。第一步先建立本地分支。第二步将分支送出到遠端。這就是我們要的分支了。第三步，附帶可以同步一下本地分支的tags和branch。否則遠端庫裡面沒有。
根本不用在遠端還在建立一個分支取合并，太麻煩了。
如下示例：
git checkout -b branchElectron7 78.0.3904.130 為tag建立了本地分支
重新關聯遠端分支
多個遠端倉庫add後，直接切換同步與送出的代碼：
git強制覆寫本地分支，慎用！！！
git fetch --all
git reset --hard origin/master
git pull
備注：
git fetch 隻是下載下傳遠端的庫的内容，不做任何的合并
git reset 把HEAD指向剛剛下載下傳的最新的版本
git fetch origin newTestBranch:newTestBranch（newTestBranch 前面的分支為遠端分支名，後面是本地分支名）
然後git branch -v 檢視分支
确認能自己建立的newDevelop分支的存在
git reflog show HEAD@{now} -10
這個指令會把HEAD指針所有的動作顯示出來。從中可以清楚的看到，在指針中送出對應的commit id
找到需要恢複的commit ，記下前面的commit id
chromium列印二進制函數：
#include "net/base/hex_utils.h"
auto sss = base::StringPiece(info.content_disposition);
LOG(INFO) << net::HexDump(sss);
Git Cookbook
A collection of git recipes to do common git tasks.
See also Git Tips.
Introduction
Chromium-specific Git Extensions
Excluding file(s) from git-cl, while preserving them for later use
Method #1: Reset your current branch, and selectively commit files
Method #2: Create a new branch, reset, then commit files to preserve
Method #3: Cherry-pick changes into review branches
Sharing code between multiple machines
Reverting commits
Retrieving, or diffing against an old file revision
Reusing a Git mirror
This is designed to be a cookbook for common command sequences/tasks relating to git, git-cl, and how they work with Chromium development. It might be a little light on explanations.
If you are new to git, or do not have much experience with a distributed version control system, you should also check out The Git Community Book for an overview of basic git concepts and general git usage. Knowing what git means by branches, commits, reverts, and resets (as opposed to what SVN means by them) will help make the following much more understandable.
Chromium ships a large number of git extensions in depot_tools. Some (like <code>git cl</code>) are required for the Chromium development workflow, while others (like <code>git map-branches</code>) are simple utilities to make your life easier. Please take a look at the full depot_tools tutorial, and at the extensive man pages for all the extensions.
Since git-cl assumes that the diff between your current branch and its tracking branch is what should be used for the CL, the goal is to remove the unwanted files from the current branch, and preserve them in another branch.
git log
See the list of your commits. Find the hash of the last commit before your changes.
git reset --soft abcdef
where abcdef is the hash found in the step above.
git commit <files_for_this_cl> -m "files to upload"
commit the files you want included in the CL here.
git new-branch new_branch_name
Create a new branch for the files that you want to exclude.
git commit -a -m "preserved files"
Commit the rest of the files.
This method creates a new branch from your current one to preserve your changes. The commits on the new branch are undone, and then only the files you want to preserve are recommitted.
git checkout -b new_branch_name
This preserves your old files.
Where abcdef is the hash found in the step above.
git commit <files_to_preserve> -m "preserved files"
Commit the found files into the new_branch_name
.
Then revert your files however you'd like in your old branch. The files listed in step 4 will be saved in <code>new_branch_name</code>
If you are systematic in creating separate local commits for independent changes, you can make a number of different changes in the same client and then cherry-pick each one into a separate review branch.
Make and commit a set of independent changes.
# see the hashes for each of your commits.
repeat checkout, cherry-pick, upload steps for each change1..n
git new-branch review-changeN
Create a new review branch tracking origin
git cherry-pick <hash of change N>
git cl upload
If a change needs updating due to review comments, you can go back to your main working branch, update the commit, and re-cherry-pick it into the review branch.
git checkout <working branch>
Make changes.
If the commit you want to update is the most recent one:
git commit --amend <files>
If not:
git commit <files>
git rebase -i origin
# use interactive rebase to squash the new commit into the old one.
# observe new hash for the change
git checkout review-changeN
git reset --hard
# remove the previous version of the change
cherry-pick <new hash of change N>
Assume Windows computer named vista, and a Linux one named penguin. Prerequisite: both machines have git clones of the main git tree.
Note that, by default, <code>gclient sync</code> will update all remotes. If your other machine (i.e., <code>penguin</code> in the above example) is not always available, <code>gclient sync</code> will timeout and fail trying to reach it. To fix this, you may exclude your machine from being fetched by default:
The command <code>git revert X</code> patches in the inverse of a particular commit. Using this command is one way of making a revert:
Git works in terms of commits, not files. Thus, working with the history of a single file requires modified version of the show and diff commands.
When invoking <code>git show</code> or <code>git diff</code>, the <code>path/to/file</code> is not relative the the current directory. It must be the full path from the directory where the .git directory lives. This is different from invoking <code>git log</code> which understands relative paths.
If you have a nearby copy of a Git repo, you can quickly bootstrap your copy from that one then adjust it to point it at the real upstream one.
Clone a nearby copy of the code you want: git clone coworker-machine:/path/to/repo
Change the URL your copy fetches from to point at the real git repo: git set-url origin https://chromium.googlesource.com/chromium/src.git
Update your copy: git fetch
Delete any extra branches that you picked up in the initial clone: git prune origin