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