Merge pull request #2093 from preco21/master

Translate docs into korean #2 + added link of power-save-blocker API to README
This commit is contained in:
Cheng Zhao 2015-07-05 21:21:56 +08:00
commit 4e94e0c82f
50 changed files with 4034 additions and 218 deletions

View file

@ -0,0 +1,34 @@
# NW.js와 기술적으로 다른점 (이전 node-webkit)
__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합환경을 제공함으로써 웹 페이지에서 저수준 시스템에 접근할 수 있는 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 합니다.
하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
__1. 어플리케이션의 엔트리 포인트__
NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
`package.json`내의 main 필드에 메인 웹 페이지(index.html) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다.
Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다.
또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다.
Electron은 Node.js 런타임과 비슷하게 작동합니다. Electron의 API는 저수준이기에 브라우저 테스팅을 위해 [PhantomJS](http://phantomjs.org/)를 사용할 수도 있습니다.
__2. 빌드 시스템__
Electron은 Chromium의 모든것을 빌드하는 복잡성을 피하기 위해 [libchromiumcontent](https://github.com/brightray/libchromiumcontent)를 사용하여
Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유 라이브러리이고 Chromium Content 모듈과 종속성 라이브러리들을 포함합니다.
유저는 Electron을 빌드 하기 위해 높은 사양의 빌드용 컴퓨터를 구비할 필요가 없습니다.
__3. Node 통합__
NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
__4. 다중 컨텍스트__
만약 NW.js를 사용해본적이 있다면 Node context와 Web context의 개념을 잘 알고 있을겁니다. 이 개념은 NW.js가 구현된 방식에 따라 만들어졌습니다.
Node의 [다중 컨텍스트](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)를 사용할 경우 Electron은 웹 페이지에서 새로운 JavaScript 컨텍스트를 생성하지 않습니다.

View file

@ -0,0 +1,90 @@
# 빌드 설명서 (Linux)
## 빌드전 요구사양
* Python 2.7.x. 몇몇 CentOS와 같은 배포판들은 아직도 Python 2.6.x 버전을 사용합니다. 그래서 `python -V`를 통해 버전을 확인해 줄 필요가 있습니다.
* Node.js v0.12.x. Node를 설치하는 방법은 여러가지가 있습니다. 그중 하나는 [Node.js](http://nodejs.org) 사이트에서 소스코드를 받아 빌드하는 방법입니다.
이렇게 하면 Node를 일반 유저로 홈 디렉터리에 설치할 수 있습니다. 또는 [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories) 에서 받아올 수도 있습니다.
자세한 내용은 [Node.js 설치 방법](https://github.com/joyent/node/wiki/Installation) 을 참고하세요.
* Clang 3.4 또는 최신 버전
* GTK+ 와 libnotify의 개발용 헤더
Ubuntu를 사용하고 있다면 다음 커맨드로 설치하면 합니다:
```bash
$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
libnotify-dev libgnome-keyring-dev libgconf2-dev \
libasound2-dev libcap-dev libcups2-dev libxtst-dev \
libxss1 gcc-multilib g++-multilib
```
다른 배포판의 경우 yum과 같은 패키지 매니저를 통해 패키지를 설치 할 수 있습니다. 패키지의 이름은 대부분 비슷할 것입니다.
또는 소스코드를 내려받아 직접 빌드하는 방법도 있습니다.
## 가상머신을 사용하여 빌드 하는 경우
만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB 이상을 확보해 놓아야 합니다.
## 코드 가져오기
```bash
$ git clone https://github.com/atom/electron.git
```
## 부트 스트랩
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 필요합니다.
아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다.
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 `Makefile`은 생성되지 않습니다.
```bash
$ cd electron
$ ./script/bootstrap.py -v
```
## 빌드 하기
`Release``Debug` 두 타겟 모두 빌드 합니다:
```bash
$ ./script/build.py
```
이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일 크기는 1.3GB를 초과합니다.
이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 디버그 심볼을 포함하기 때문입니다.
파일 크기를 줄이려면 `create-dist.py` 스크립트를 실행하세요:
```bash
$ ./script/create-dist.py
```
이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다.
`Debug` 타겟만 빌드 할 수도 있습니다:
```bash
$ ./script/build.py -c D
```
빌드가 모두 끝나면 `out/D` 디렉터리에서 `electron` 디버그 바이너리를 찾을 수 있습니다.
## 정리 하기
빌드 파일들을 정리합니다:
```bash
$ ./script/clean.py
```
## 문제 해결
개발 종속성 라이브러리들을 제대로 설치했는지 확인하세요.
## 테스트
```bash
$ ./script/test.py
```

View file

@ -0,0 +1,53 @@
# 빌드 설명서 (Mac)
## 빌드전 요구 사항
* OS X >= 10.8
* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
* [node.js](http://nodejs.org) (external).
만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다:
* pyobjc
## 코드 가져오기
```bash
$ git clone https://github.com/atom/electron.git
```
## 부트 스트랩
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Xcode 프로젝트는 생성되지 않습니다.
```bash
$ cd electron
$ ./script/bootstrap.py -v
```
## 빌드 하기
`Release``Debug` 두 타겟 모두 빌드 합니다:
```bash
$ ./script/build.py
```
`Debug` 타겟만 빌드 할 수도 있습니다:
```bash
$ ./script/build.py -c D
```
빌드가 모두 끝나면 `out/D` 디렉터리에서 `Electron.app` 실행 파일을 찾을 수 있습니다.
## 32비트 지원
Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다.
## 테스트
```bash
$ ./script/test.py
```

View file

@ -0,0 +1,117 @@
# 빌드 설명서 (Windows)
## 빌드전 요구 사항
* Windows 7 / Server 2008 R2 또는 최신 버전
* Visual Studio 2013 - [VS 2013 커뮤니티 에디션 무료 다운로드](http://www.visualstudio.com/products/visual-studio-community-vs)
* [Python 2.7](http://www.python.org/download/releases/2.7/)
* [Node.js](http://nodejs.org/download/)
* [git](http://git-scm.com)
현재 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서
사용기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을 빌드할 수도 있습니다.
Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다.
하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다.
**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다.
## 코드 가져오기
```powershell
git clone https://github.com/atom/electron.git
```
## 부트 스트랩
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다.
```powershell
cd electron
python script\bootstrap.py -v
```
## 빌드 하기
`Release``Debug` 두 타겟 모두 빌드 합니다:
```powershell
python script\build.py
```
`Debug` 타겟만 빌드 할 수도 있습니다:
```powershell
python script\build.py -c D
```
빌드가 모두 끝나면 `out/D` 디렉터리에서 `atom.exe` 실행 파일을 찾을 수 있습니다.
## 64비트 빌드
64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
```powershell
python script\bootstrap.py -v --target_arch=x64
```
다른 빌드 단계도 정확하게 같습니다.
## 테스트
```powershell
python script\test.py
```
## 문제 해결
### Command xxxx not found
만약 `Command xxxx not found`와 같은 형식의 에러가 발생했다면 `VS2012 Command Prompt` 콘솔로 빌드 스크립트를 실행해볼 필요가 있습니다.
### Fatal internal compiler error: C1001
Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 확인하세요.
### Assertion failed: ((handle))->activecnt >= 0
Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 있습니다:
```
Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
Traceback (most recent call last):
File "script/bootstrap.py", line 87, in <module>
sys.exit(main())
File "script/bootstrap.py", line 22, in main
update_node_modules('.')
File "script/bootstrap.py", line 56, in update_node_modules
execute([NPM, 'install'])
File "/home/zcbenz/codes/raven/script/lib/util.py", line 118, in execute
raise e
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
```
이 버그는 Cygwin python과 Win32 node를 같이 사용할 경우 발생합니다.
부트스트랩 스크립트에서 Win32 python을 사용함으로써 이 문제를 해결할 수 있습니다 (`C:\Python27` 디렉터리에 python이 설치되었다는 것을 가정하면):
```bash
/cygdrive/c/Python27/python.exe script/bootstrap.py
```
### LNK1181: cannot open input file 'kernel32.lib'
32bit node.js를 다시 설치하세요.
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](http://stackoverflow.com/a/25095327/102704):
```powershell
mkdir ~\AppData\Roaming\npm
```
### node-gyp is not recognized as an internal or external command
Git Bash로 빌드 했을 때 이러한 에러가 발생할 수 있습니다. 반드시 PowerShell이나 VS2012 Command Prompt에서 빌드를 진행해야 합니다.

View file

@ -0,0 +1,51 @@
# 빌드 시스템 개요
Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다.
프로젝트 설정은 `.gyp``.gypi` 파일에서 볼 수 있습니다.
## gyp 파일들
Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다:
* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
* `vendor/brightray/brightray.gyp``brightray`의 빌드 과정을 정의하고 Chromium과의 링킹에 대한 기본적인 설정을 포함합니다.
* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
## 구성요소 빌드
Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다.
이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다.
이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다.
Electron도 상당히 비슷한 접근을 했습니다:
`Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고
`Release`빌드 시엔 정적 라이브러리 버전의 컴포넌트를 사용합니다.
이렇게 각 빌드의 단점을 상호 보완하여 디버그 시 빌드 속도는 향상되고 배포판 빌드 시 공유 라이브러리의 단점은 제거했습니다.
## 부트스트랩 최소화
모든 사전 빌드 된 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다.
기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다.
만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유 라이브러리만 다운로드할 수 있습니다:
```bash
$ ./script/bootstrap.py --dev
$ ./script/build.py -c D
```
## 프로젝트 생성 (two-phrase)
Electron은 `Release``Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다.
그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다.
이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다.
## 타겟 이름
많은 프로젝트에서 타겟 이름을 `Release``Debug`를 사용하는데 반해 Electron은 `R``D`를 대신 사용합니다.
이유는 가끔 알 수 없는 이유(randomly)로 `Release``Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
전술한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.

View file

@ -4,20 +4,19 @@
C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다.
파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다.
파이선의 버전은 2.7을 사용합니다.
## CoffeeScript
CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다, 동시에 다음 규칙도 따릅니다:
CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다. 동시에 다음 규칙도 따릅니다:
* Google의 코딩 스타일에도 맞추기 위해, 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
* Google의 코딩 스타일에도 맞추기 위해 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
* 파일 이름의 공백은 `_`대신에 `-`을 사용하여야 합니다. 예를 들어 `file_name.coffee`
`file-name.coffee`로 고쳐야합니다, 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
보통 `module-name`형식이기 때문입니다, 이 규칙은 '.coffee' 파일에만 적용됩니다.
`file-name.coffee`로 고쳐야합니다. 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
보통 `module-name`형식이기 때문입니다. 이 규칙은 '.coffee' 파일에만 적용됩니다.
## API 이름
새로운 API를 만들 땐, getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어,
새로운 API를 만들 땐 getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어
`.getText()``.setText(text)`대신에 `.text([text])`형식으로 설계하면 됩니다.
포럼에 이 문제에 대한 [논의](https://github.com/atom/electron/issues/46)가 있습니다.

View file

@ -0,0 +1,44 @@
# 디버거에서 디버그 심볼 서버 설정
디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 함수에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다.
서버 사용법은 [Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다. 이 문서를 참조하세요.
참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라 디버깅이 쉽지 않을 수 있습니다.
Inlining, tail call 등의 컴파일러 최적화에 의해 디버거가 모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여질 수 있습니다.
유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
공식적인 Electron의 심볼 서버의 URL은 http://54.249.141.255:8086/atom-shell/symbols 입니다.
일단 이 URL에 직접적으로 접근할 수는 없습니다: 디버깅 툴에 심볼의 경로를 추가해야합니다.
아래의 예제를 참고하면 로컬 캐시 디렉터리는 서버로부터 중복되지 않게 PDB를 가져오는데 사용됩니다.
`c:\code\symbols` 캐시 디렉터리를 사용중인 OS에 맞춰 적당한 경로로 변경하세요.
## Windbg에서 심볼 서버 사용하기
Windbg 심볼 경로는 구분자와 *(별) 문자로 설정되어 있습니다.
Electron 심볼 서버만을 사용하려면 심볼 경로의 엔트리를 추가해야 합니다 (__참고:__ `c:\code\symbols` 디렉터리 경로를 PC가 원하는 경로로 수정할 수 있습니다):
```
SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
```
Windbg 메뉴 또는 `.sympath` 커맨드를 이용하여 환경에 `_NT_SYMBOL_PATH` 문자열을 설정합니다.
만약 Microsoft의 심볼서버로 부터 심볼을 받아오려면 다음과 같이 리스팅을 먼저 해야합니다:
```
SRV*c:\code\symbols\*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
```
## Visual Studio에서 심볼 서버 사용하기
<img src='http://mdn.mozillademos.org/files/733/symbol-server-vc8express-menu.jpg'>
<img src='http://mdn.mozillademos.org/files/2497/2005_options.gif'>
## 문제 해결: Symbols will not load
Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 출력합니다:
```
> !sym noisy
> .reload /f chromiumcontent.dll
```

View file

@ -0,0 +1,48 @@
# 소스 코드 디렉터리 구조
## 개요
Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우리는 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다.
이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
## 소스 코드 구조
* **atom** - Electron의 소스코드.
* **app** - 시스템 엔트리 코드.
* **browser** - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. 주 랜더러와 웹 페이지 관리관련 코드.
* **lib** - 메인 프로세스 초기화 코드의 자바스크립트 파트.
* **ui** - 크로스 플랫폼에 대응하는 UI 구현.
* **cocoa** - 코코아 특정 소스 코드.
* **gtk** - GTK+ 특정 소스 코드.
* **win** - Windows GUI 특정 소스 코드.
* **default_app** - 어플리케이션이 제공되지 않으면 기본적으로 사용될 페이지.
* **api** - 메인 프로세스 API들의 구현.
* **lib** - API 구현의 자바스크립트 파트.
* **net** - 네트워크 관련 코드.
* **mac** - Mac 특정 Objective-C 소스 코드.
* **resources** - 아이콘들, 플랫폼 종속성 파일들, 기타 등등.
* **renderer** - 렌더러 프로세스에서 작동하는 코드들.
* **lib** - 렌더러 프로세스 초기화 코드의 자바스크립트 파트.
* **api** - 렌더러 프로세스 API들의 구현.
* **lib** - API 구현의 자바스크립트 파트.
* **common** - 메인 프로세스와 렌더러 프로세스에서 공유하는 코드. 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드가 포함.
* **lib** - 공통 자바스크립트 초기화 코드.
* **api** - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들.
* **lib** - API 구현의 자바스크립트 파트.
* **chromium_src** - 복사된 Chromium 소스 코드.
* **docs** - 참조 문서.
* **spec** - 자동화된 테스트.
* **atom.gyp** - Electron의 빌드 규칙.
* **common.gypi** - 컴파일러 설정 및 `node``breakpad` 등의 구성요소를 위한 빌드 규칙.
## 그외 디렉터리 구조
* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
* **out** - `ninja`의 임시 출력 디렉터리.
* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리.
* **external_binaries** - `gyp`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.