Fix typos, add more files
This commit is contained in:
Plusb Preco
parent
bf5b084945
commit
ebb031dafe
45 changed files with 3450 additions and 239 deletions
|
|
@ -1,49 +1,34 @@
|
|||
# NW.js와 기술적으로 다른점 (이전 node-webkit)
|
||||
# NW.js와 기술적으로 다른점 (이전 node-webkit)
|
||||
|
||||
__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
|
||||
|
||||
Like NW.js, Electron provides a platform to write desktop applications
|
||||
with JavaScript and HTML and has Node integration to grant access to low level
|
||||
system in web pages.
|
||||
NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합환경을 제공함으로써 웹 페이지에서 저수준 시스템에 접근할 수 있는 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 합니다.
|
||||
|
||||
But there are also fundamental differences between the two projects that make
|
||||
Electron a completely separate product from NW.js:
|
||||
하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
|
||||
|
||||
__1. 어플리케이션의 엔트리 포인트__
|
||||
|
||||
In NW.js, the main entry of an application is a web page. You specify a
|
||||
main page in the `package.json` and it is opened in a browser window as
|
||||
the application's main window.
|
||||
NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
|
||||
`package.json`내의 main 필드에 메인 웹 페이지(index.html) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다.
|
||||
|
||||
In Electron, the entry point is a JavaScript script. Instead of
|
||||
providing a URL directly, you manually create a browser window and load
|
||||
an HTML file using the API. You also need to listen to window events
|
||||
to decide when to quit the application.
|
||||
Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다.
|
||||
또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다.
|
||||
|
||||
Electron works more like the Node.js runtime. Electron's APIs are lower level
|
||||
so you can use it for browser testing in place of [PhantomJS](http://phantomjs.org/).
|
||||
Electron은 Node.js 런타임과 비슷하게 작동합니다. Electron의 API는 저수준이기에 브라우저 테스팅을 위해 [PhantomJS](http://phantomjs.org/)를 사용할 수도 있습니다.
|
||||
|
||||
__2. 빌드 시스템__
|
||||
|
||||
In order to avoid the complexity of building the whole Chromium, Electron uses
|
||||
[libchromiumcontent](https://github.com/brightray/libchromiumcontent) to access
|
||||
Chromium's Content API. libchromiumcontent is a single, shared library that
|
||||
includes the Chromium Content module and all its dependencies. Users don't
|
||||
need a powerful machine to build Electron.
|
||||
Electron은 Chromium의 모든것을 빌드하는 복잡성을 피하기 위해 [libchromiumcontent](https://github.com/brightray/libchromiumcontent)를 사용하여
|
||||
Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유 라이브러리이고 Chromium Content 모듈과 종속성 라이브러리들을 포함합니다.
|
||||
유저는 Electron을 빌드 하기 위해 높은 사양의 빌드용 컴퓨터를 구비할 필요가 없습니다.
|
||||
|
||||
__3. Node 통합__
|
||||
|
||||
In NW.js, the Node integration in web pages requires patching Chromium to
|
||||
work, while in Electron we chose a different way to integrate libuv loop with
|
||||
each platform's message loop to avoid hacking Chromium. See the
|
||||
[`node_bindings`](../../atom/common/) code for how that was done.
|
||||
NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
|
||||
[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
|
||||
|
||||
__4. 다중 컨텍스트__
|
||||
|
||||
If you are an experienced NW.js user, you should be familiar with the
|
||||
concept of Node context and web context. These concepts were invented because
|
||||
of how NW.js was implemented.
|
||||
만약 NW.js를 사용해본적이 있다면 Node context와 Web context의 개념을 잘 알고 있을겁니다. 이 개념은 NW.js가 구현된 방식에 따라 만들어졌습니다.
|
||||
|
||||
By using the [multi-context](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)
|
||||
feature of Node, Electron doesn't introduce a new JavaScript context in web
|
||||
pages.
|
||||
Node의 [다중 컨텍스트](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)를 사용할 경우 Electron은 웹 페이지에서 새로운 JavaScript 컨텍스트를 생성하지 않습니다.
|
||||
|
|
|
|||
|
|
@ -2,16 +2,14 @@
|
|||
|
||||
## 빌드전 요구사양
|
||||
|
||||
* Python 2.7.x. Some distributions like CentOS still use Python 2.6.x
|
||||
so you may need to check your Python version with `python -V`.
|
||||
* Node.js v0.12.x. There are various ways to install Node. One can download
|
||||
source code from [Node.js] (http://nodejs.org) and compile from source.
|
||||
Doing so permits installing Node to your own home directory as a standard user.
|
||||
Or try repositories such as [NodeSource] (https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)
|
||||
* Clang 3.4 or later
|
||||
* Development headers of GTK+ and libnotify
|
||||
* 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의 개발용 헤더
|
||||
|
||||
On Ubuntu, install the following libraries:
|
||||
Ubuntu를 사용하고 있다면 다음 커맨드로 설치하면 합니다:
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
|
||||
|
|
@ -20,14 +18,12 @@ $ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
|
|||
libxss1 gcc-multilib g++-multilib
|
||||
```
|
||||
|
||||
Other distributions may offer similar packages for installation via package
|
||||
managers such as yum. Or one can compile from source code.
|
||||
|
||||
다른 배포판의 경우 yum과 같은 패키지 매니저를 통해 패키지를 설치 할 수 있습니다. 패키지의 이름은 대부분 비슷할 것입니다.
|
||||
또는 소스코드를 내려받아 직접 빌드하는 방법도 있습니다.
|
||||
|
||||
## 가상머신을 사용하여 빌드 하는 경우
|
||||
|
||||
If you plan to build electron on a virtual machine, you will need a fixed-size
|
||||
device container of at least 25 gigabytes in size.
|
||||
만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB 이상을 확보해 놓아야 합니다.
|
||||
|
||||
|
||||
## 코드 가져오기
|
||||
|
|
@ -38,10 +34,10 @@ $ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. You must have Python 2.7.x for the script to succeed.
|
||||
Downloading certain files could take a long time. Notice that we are using
|
||||
`ninja` to build Electron so there is no `Makefile` generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 필요합니다.
|
||||
아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 `Makefile`은 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
|
|
@ -50,48 +46,42 @@ $ ./script/bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
If you would like to build both `Release` and `Debug` targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
This script will cause a very large Electron executable to be placed in
|
||||
the directory `out/R`. The file size is in excess of 1.3 gigabytes. This
|
||||
happens because the Release target binary contains debugging symbols.
|
||||
To reduce the file size, run the `create-dist.py` script:
|
||||
이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일 크기는 1.3GB를 초과합니다.
|
||||
이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 디버그 심볼을 포함하기 때문입니다.
|
||||
파일 크기를 줄이려면 `create-dist.py` 스크립트를 실행하세요:
|
||||
|
||||
```bash
|
||||
$ ./script/create-dist.py
|
||||
```
|
||||
|
||||
This will put a working distribution with much smaller file sizes in
|
||||
the `dist` directory. After running the create-dist.py script, you
|
||||
may want to remove the 1.3+ gigabyte binary which is still in out/R.
|
||||
이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
|
||||
create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다.
|
||||
|
||||
You can also build the `Debug` target only:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find the `electron` debug binary
|
||||
under `out/D`.
|
||||
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `electron` 디버그 바이너리를 찾을 수 있습니다.
|
||||
|
||||
## 정리 하기
|
||||
|
||||
|
||||
To clean the build files:
|
||||
빌드 파일들을 정리합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/clean.py
|
||||
```
|
||||
|
||||
|
||||
## 문제 해결
|
||||
|
||||
Make sure you have installed all the build dependencies.
|
||||
개발 종속성 라이브러리들을 제대로 설치했는지 확인하세요.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@
|
|||
* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
|
||||
* [node.js](http://nodejs.org) (external).
|
||||
|
||||
If you are using the python downloaded by Homebrew, you also need to install
|
||||
following python modules:
|
||||
만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다:
|
||||
|
||||
* pyobjc
|
||||
|
||||
|
|
@ -19,9 +18,8 @@ $ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Xcode project generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Xcode 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
|
|
@ -30,24 +28,23 @@ $ ./script/bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
Build both `Release` and `Debug` targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
You can also only build the `Debug` target:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `Electron.app` under `out/D`.
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `Electron.app` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 32비트 지원
|
||||
|
||||
Electron can only be built for 64bit target on OS X, and there is no plan to
|
||||
support 32bit OS X in future.
|
||||
Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +1,23 @@
|
|||
# 빌드 설명서 (Windows)
|
||||
# 빌드 설명서 (Windows)
|
||||
|
||||
## 빌드전 요구 사항
|
||||
|
||||
* Windows 7 / Server 2008 R2 or higher
|
||||
* Visual Studio 2013 - [download VS 2013 Community Edition for
|
||||
free](http://www.visualstudio.com/products/visual-studio-community-vs)
|
||||
* 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)에서 Electron을 빌드할 수 있는 timebombed Windows 버전을 확인할 수 있습니다.
|
||||
|
||||
If you don't have a Windows installation at the moment,
|
||||
[modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads) has
|
||||
timebombed versions of Windows that you can use to build Electron.
|
||||
|
||||
The building of Electron is done entirely with command-line scripts, so you
|
||||
can use any editor you like to develop Electron, but it also means you can
|
||||
not use Visual Studio for the development. Support of building with Visual
|
||||
Studio will come in the future.
|
||||
Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다.
|
||||
하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다.
|
||||
|
||||
**Note:** Even though Visual Studio is not used for building, it's still
|
||||
**required** because we need the build toolchains it provided.
|
||||
**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다.
|
||||
|
||||
## 코드 가져오기
|
||||
|
||||
|
|
@ -29,9 +27,8 @@ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Visual Studio project generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```powershell
|
||||
cd electron
|
||||
|
|
@ -40,30 +37,29 @@ python script\bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
Build both Release and Debug targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py
|
||||
```
|
||||
|
||||
You can also only build the Debug target:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `atom.exe` under `out\D`.
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `atom.exe` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 64비트 빌드
|
||||
|
||||
To build for the 64bit target, you need to pass `--target_arch=x64` when running
|
||||
the bootstrap script:
|
||||
64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
|
||||
|
||||
```powershell
|
||||
python script\bootstrap.py -v --target_arch=x64
|
||||
```
|
||||
|
||||
The other building steps are exactly the same.
|
||||
다른 빌드 단계도 정확하게 같습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
@ -75,17 +71,15 @@ python script\test.py
|
|||
|
||||
### Command xxxx not found
|
||||
|
||||
If you encountered an error like `Command xxxx not found`, you may try to use
|
||||
the `VS2012 Command Prompt` console to execute the build scripts.
|
||||
만약 `Command xxxx not found`와 같은 형식의 에러가 발생했다면 `VS2012 Command Prompt` 콘솔로 빌드 스크립트를 실행해볼 필요가 있습니다.
|
||||
|
||||
### Fatal internal compiler error: C1001
|
||||
|
||||
Make sure you have the latest Visual Studio update installed.
|
||||
Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 확인하세요.
|
||||
|
||||
### Assertion failed: ((handle))->activecnt >= 0
|
||||
|
||||
If building under Cygwin, you may see `bootstrap.py` failed with following
|
||||
error:
|
||||
Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 있습니다:
|
||||
|
||||
```
|
||||
Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
|
||||
|
|
@ -102,9 +96,8 @@ Traceback (most recent call last):
|
|||
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
|
||||
```
|
||||
|
||||
This is caused by a bug when using Cygwin python and Win32 node together. The
|
||||
solution is to use the Win32 python to execute the bootstrap script (supposing
|
||||
you have installed python under `C:\Python27`):
|
||||
이 버그는 Cygwin python과 Win32 node를 같이 사용할 경우 발생합니다.
|
||||
부트스트랩 스크립트에서 Win32 python을 사용함으로써 이 문제를 해결할 수 있습니다 (`C:\Python27` 디렉터리에 python이 설치되었다는 것을 가정하면):
|
||||
|
||||
```bash
|
||||
/cygdrive/c/Python27/python.exe script/bootstrap.py
|
||||
|
|
@ -112,11 +105,11 @@ you have installed python under `C:\Python27`):
|
|||
|
||||
### LNK1181: cannot open input file 'kernel32.lib'
|
||||
|
||||
Try reinstalling 32bit node.js.
|
||||
32bit node.js를 다시 설치하세요.
|
||||
|
||||
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
|
||||
|
||||
Simply making that directory [should fix the problem](http://stackoverflow.com/a/25095327/102704):
|
||||
간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](http://stackoverflow.com/a/25095327/102704):
|
||||
|
||||
```powershell
|
||||
mkdir ~\AppData\Roaming\npm
|
||||
|
|
@ -124,5 +117,4 @@ mkdir ~\AppData\Roaming\npm
|
|||
|
||||
### node-gyp is not recognized as an internal or external command
|
||||
|
||||
You may get this error if you are using Git Bash for building, you should use
|
||||
PowerShell or VS2012 Command Prompt instead.
|
||||
Git Bash로 빌드 했을 때 이러한 에러가 발생할 수 있습니다. 반드시 PowerShell이나 VS2012 Command Prompt에서 빌드를 진행해야 합니다.
|
||||
|
|
|
|||
|
|
@ -1,64 +1,51 @@
|
|||
# 빌드 시스템 개요
|
||||
# 빌드 시스템 개요
|
||||
|
||||
Electron uses `gyp` for project generation, and `ninja` for building, project
|
||||
configurations can be found in `.gyp` and `.gypi` files.
|
||||
Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다.
|
||||
프로젝트 설정은 `.gyp` 와 `.gypi` 파일에서 볼 수 있습니다.
|
||||
|
||||
## Gyp 파일들
|
||||
## gyp 파일들
|
||||
|
||||
Following `gyp` files contain the main rules of building Electron:
|
||||
Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다:
|
||||
|
||||
* `atom.gyp` defines how Electron itself is built.
|
||||
* `common.gypi` adjusts the build configurations of Node to make it build
|
||||
together with Chromium.
|
||||
* `vendor/brightray/brightray.gyp` defines how `brightray` is built, and
|
||||
includes the default configurations of linking with Chromium.
|
||||
* `vendor/brightray/brightray.gypi` includes general build configurations about
|
||||
building.
|
||||
* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
|
||||
* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
|
||||
* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고 Chromium과의 링킹에 대한 기본적인 설정을 포함합니다.
|
||||
* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
|
||||
|
||||
## 구성요소 빌드
|
||||
|
||||
Since Chromium is quite a large project, the final linking stage would take
|
||||
quite a few minutes, making it hard for development. In order to solve this,
|
||||
Chromium introduced the "component build", which builds each component as a
|
||||
separate shared library, making linking very quick but sacrificing file size
|
||||
and performance.
|
||||
Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다.
|
||||
이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다.
|
||||
이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다.
|
||||
|
||||
In Electron we took a very similar approach: for `Debug` builds, the binary
|
||||
will be linked to shared library version of Chromium's components to achieve
|
||||
fast linking time; for `Release` builds, the binary will be linked to the static
|
||||
library versions, so we can have the best possible binary size and performance.
|
||||
Electron도 상당히 비슷한 접근을 했습니다:
|
||||
`Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고
|
||||
`Release`빌드 시엔 정적 라이브러리 버전의 컴포넌트를 사용합니다.
|
||||
이렇게 각 빌드의 단점을 상호 보완하여 디버그 시 빌드 속도는 향상되고 배포판 빌드 시 공유 라이브러리의 단점은 제거했습니다.
|
||||
|
||||
## 부트스트랩 최소화
|
||||
|
||||
All of Chromium's prebuilt binaries are downloaded when running the bootstrap
|
||||
script. By default both static libraries and shared libraries will be
|
||||
downloaded and the final size should be between 800MB and 2GB according to the
|
||||
platform.
|
||||
모든 사전 빌드 된 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다.
|
||||
기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다.
|
||||
|
||||
If you only want to build Electron quickly for testing or development, you
|
||||
can only download the shared library versions by passing the `--dev` parameter:
|
||||
만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유 라이브러리만 다운로드할 수 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/bootstrap.py --dev
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
## Two-phrase 프로젝트 생성
|
||||
## 프로젝트 생성 (two-phrase)
|
||||
|
||||
Electron links with different sets of libraries in `Release` and `Debug`
|
||||
builds, however `gyp` doesn't support configuring different link settings for
|
||||
different configurations.
|
||||
Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다.
|
||||
그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다.
|
||||
|
||||
To work around this Electron uses a `gyp` variable
|
||||
`libchromiumcontent_component` to control which link settings to use, and only
|
||||
generates one target when running `gyp`.
|
||||
이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다.
|
||||
|
||||
## 타겟 이름
|
||||
|
||||
Unlike most projects that use `Release` and `Debug` as target names, Electron
|
||||
uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
|
||||
only one `Release` or `Debug` build configuration is defined, and Electron has
|
||||
to only generate one target for one time as stated above.
|
||||
많은 프로젝트에서 타겟 이름을 `Release` 와 `Debug`를 사용하는데 반해 Electron은 `R`과 `D`를 대신 사용합니다.
|
||||
이유는 가끔 알 수 없는 이유(randomly)로 `Release` 와 `Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
|
||||
전술한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
|
||||
|
||||
This only affects developers, if you are only building Electron for rebranding
|
||||
you are not affected.
|
||||
이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.
|
|||
|
||||
## 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)가 있습니다.
|
||||
|
|
|
|||
|
|
@ -39,8 +39,8 @@ Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우
|
|||
## 그외 디렉터리 구조
|
||||
|
||||
* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
|
||||
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트, `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
|
||||
* **vendor** - 소스코드의 서드파티 종속성 코드, 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에,
|
||||
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
|
||||
* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
|
||||
우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
|
||||
* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
|
||||
* **out** - `ninja`의 임시 출력 디렉터리.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue