Standardize overview
This commit is contained in:
parent
009e228218
commit
842ba6aea6
1 changed files with 30 additions and 29 deletions
|
@ -1,71 +1,72 @@
|
|||
# Build system overview
|
||||
# Build System Overview
|
||||
|
||||
Electron uses `gyp` for project generation, and `ninja` for building, project
|
||||
configurations can be found in `.gyp` and `.gypi` files.
|
||||
Electron uses `gyp` for project generation and `ninja` for building. Project
|
||||
configurations can be found in the `.gyp` and `.gypi` files.
|
||||
|
||||
## Gyp files
|
||||
## Gyp Files
|
||||
|
||||
Following `gyp` files contain the main rules of building Electron:
|
||||
Following `gyp` files contain the main rules for building Electron:
|
||||
|
||||
* `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.gyp` defines how `brightray` is built and
|
||||
includes the default configurations for linking with Chromium.
|
||||
* `vendor/brightray/brightray.gypi` includes general build configurations about
|
||||
building.
|
||||
|
||||
## Component build
|
||||
## Component Build
|
||||
|
||||
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
|
||||
Since Chromium is quite a large project, the final linking stage can take
|
||||
quite a few minutes, which makes 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.
|
||||
|
||||
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
|
||||
will be linked to a 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.
|
||||
|
||||
## Minimal bootstrapping
|
||||
## Minimal Bootstrapping
|
||||
|
||||
All of Chromium's prebuilt binaries(libchromiumcontent) are downloaded when
|
||||
All of Chromium's prebuilt binaries (`libchromiumcontent`) 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.
|
||||
depending on the platform.
|
||||
|
||||
By default, libchromiumcontent is downloaded from Amazon Web Services.
|
||||
If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, bootrstrap
|
||||
By default, `libchromiumcontent` is downloaded from Amazon Web Services.
|
||||
If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, the bootstrap
|
||||
script will download from it.
|
||||
[libchromiumcontent-qiniu-mirror](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
|
||||
is a mirror for libchromiumcontent. If you have trouble in accessing AWS, you can
|
||||
switch download address to it via `export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
|
||||
[`libchromiumcontent-qiniu-mirror`](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
|
||||
is a mirror for `libchromiumcontent`. If you have trouble in accessing AWS, you
|
||||
can switch the download address to it via
|
||||
`export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
|
||||
|
||||
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:
|
||||
can download just the shared library versions by passing the `--dev` parameter:
|
||||
|
||||
```bash
|
||||
$ ./script/bootstrap.py --dev
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
## Two-phrase project generation
|
||||
## Two-Phrase Project Generation
|
||||
|
||||
Electron links with different sets of libraries in `Release` and `Debug`
|
||||
builds, however `gyp` doesn't support configuring different link settings for
|
||||
builds. `gyp`, however, doesn't support configuring different link settings for
|
||||
different configurations.
|
||||
|
||||
To work around this Electron uses a `gyp` variable
|
||||
`libchromiumcontent_component` to control which link settings to use, and only
|
||||
`libchromiumcontent_component` to control which link settings to use and only
|
||||
generates one target when running `gyp`.
|
||||
|
||||
## Target names
|
||||
## Target Names
|
||||
|
||||
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.
|
||||
only one `Release` or `Debug` build configuration defined, and Electron only has
|
||||
to generate one target at a time as stated above.
|
||||
|
||||
This only affects developers, if you are only building Electron for rebranding
|
||||
This only affects developers, if you are just building Electron for rebranding
|
||||
you are not affected.
|
||||
|
|
Loading…
Reference in a new issue