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:
commit
4e94e0c82f
50 changed files with 4034 additions and 218 deletions
34
docs/development/atom-shell-vs-node-webkit-ko.md
Normal file
34
docs/development/atom-shell-vs-node-webkit-ko.md
Normal 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 컨텍스트를 생성하지 않습니다.
|
90
docs/development/build-instructions-linux-ko.md
Normal file
90
docs/development/build-instructions-linux-ko.md
Normal 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
|
||||
```
|
53
docs/development/build-instructions-mac-ko.md
Normal file
53
docs/development/build-instructions-mac-ko.md
Normal 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
|
||||
```
|
117
docs/development/build-instructions-windows-ko.md
Normal file
117
docs/development/build-instructions-windows-ko.md
Normal 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에서 빌드를 진행해야 합니다.
|
51
docs/development/build-system-overview-ko.md
Normal file
51
docs/development/build-system-overview-ko.md
Normal 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 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.
|
|
@ -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)가 있습니다.
|
||||
|
|
44
docs/development/setting-up-symbol-server-ko.md
Normal file
44
docs/development/setting-up-symbol-server-ko.md
Normal 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
|
||||
```
|
48
docs/development/source-code-directory-structure-ko.md
Normal file
48
docs/development/source-code-directory-structure-ko.md
Normal 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`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.
|
Loading…
Add table
Add a link
Reference in a new issue