GN Quick Start Guide

GN Quick Start Guide running GN

You can enter GN run directly from the command line. Because the Depot_tools (path should have been set in your environment variable path), there is a script with the same name in the tool directory. This script will find the binary file in the current directory and run it. Build a Build

When using GYP, the system generates debug and release compilation directories based on the corresponding configuration parameters. But GN is not the same, you can configure your compilation parameters and build directory arbitrarily. It is also automatically regenerated when it detects that the ninja file needs to be updated at compile time.

Reborn into a compiled directory:

GN Gen Out/my_build

Incoming compilation parameters

To set compilation parameters for the compiled directory:

GN args Out/my_build

A text editor will then pop up and enter the compilation parameters as follows:

Is_component_build = True
Is_debug = False

See all the parameter variables and their default values:

GN args--list Out/my_build

This command must specify the compilation directory, because different directories have different parameter values.

Chrome developers can also refer to the Chrome-specific build configuration instructions for more information. cross-compilation configuration (cross-compiling to a target OS or architecture)

Run GN args Out/default (replace with the directory you need) and add one or more of the following common cross-compilation options:

Target_os = "ChromeOS"
target_os = "Android"

target_cpu = "Arm"
target_cpu = "x86"
target_cpu = "x64"

Please refer to Gncrosscompiles for more information. Goma configuration

Run GN args Out/default (replace with the directory you need). and add:

Use_goma = True
Goma_dir = "~/foo/bar/goma"

If your Goma is installed in the default path (~/goma), you can omit the Goma_dir parameter. Configuring Component Mode

Run the GN args Out/default and add:

Is_component_build = True

Detailed Steps Add a compilation file (BUILD.GN)

Create a file tools/gn/tutorial/build.gn and enter:

Executable ("Hello_world") {
  sources = [
    "hello_world.cc",
  ]
}

There should be a hello_world.cc file in the target directory that contains the content you expect. Now we just need to tell the compiler that it needs to process the compiled file. Open the Build.gn file under the root directory (SRC) and add the newly created compilation file to the dependencies of one of the root group (where each group is a collection of other targets):

Group ("root") {
  deps = [
    ...
    ] URL ",
    "//tools/gn/tutorial:hello_world ",
  ]
}

You can see that there is a "//" symbol in front of your target file tag (that is, the root directory of the source code, which is the SRC directory), followed by a specific path, followed by a colon, and finally the target name of your project. Test your new project

In the source root directory, use command-line operations:

GN Gen Out/default
ninja-c out/default hello_world
Out/default/hello_world

GN encourages the use of the same name for static libraries. When compiling one of these, you can pass the label text without the prefix "//" to Ninja:

Ninja-c Out/default Tools/gn/tutorial:hello_world

Claim Dependent

Now to build a static library, it has a function to say hello to anyone. These are included in a hello.cc file. Open Tools/gn/tutorial/build.gn and add the following configuration static library text to the bottom of the file:

Static_library ("Hello") {
  sources = [
    "hello.cc",
  ]
}

I'll add another executable project that relies on the static library above:

Executable ("Say_hello") {
  sources = [
    "say_hello.cc",
  ]
  deps = [
    ": Hello",
  ]
}

This EXE project contains a source file and relies on the Lib project above. Lib is introduced through the Deps dependencies in the EXE. You can also use full-path text//tools/gn/tutorial:hello, but if you introduce a project that is in the same build file, you can use the abbreviation: Hello. test the Static library

In the source root directory, enter:

Ninja-c Out/default Say_hello
Out/default/say_hello

You don't need to run the GN command again. GN will automatically regenerate the ninja file when the Build.gn file is changed. You know, this usually happens when ninja just runs, it prints out [1/1] Regenerating ninja files. precompiled settings (Compiler settings)

One of the new features of our Hello Lib project is that you can say hello to two people at the same time. This function is controlled by the macro definition two_people. We can add this in the project:

Static_library ("Hello") {
  sources = [
    "hello.cc",
  ]
  defines = [
    "Two_people",
  ]
}

put some settings into config (putting settings in a config)

However, the project using Lib also needs to know this definition, put the definition into the LIB project, only the files in this project take effect. If other projects contain hello.h, they cannot see the definition. If you want to see this definition, each project that introduces this LIB must define two_people.

GN has a concept of "config" that can put some settings inside. Now let's create a "config" and put the predefined macros we need inside:

Config ("Hello_config") {
  defines = [
    "Two_people",
  ]
}

To introduce these settings in the target project, you only need to list the desired configuration in the configs option of the target:

Static_library ("Hello") {
  ...
  Configs + = [
    ": Hello_config",
  ]
}

This place you need to use + =, not =, because each target project build compiles a series of default configurations. What you have to do is add the new configuration to the default configuration instead of overriding it all. If you need to see the default configuration, you can use the print function or the desc command line subcommand in the compile file (BUILD.GN) (The following example will describe it). Dependency Configuration item (Dependent configs)

The method described above is a good way to encapsulate our configuration, but it still requires each project that uses LIB to be set in their own configuration. If every project that uses LIB can get these configurations automatically, how good is that? Now to change the configuration of the following Lib:

Static_library ("Hello") {
  sources = [
    "hello.cc",
  ]
  all_dependent_configs = [
    ": Hello_config"
  ]
}

This applies the hello_config configuration to the Hello project itself, as well as all dependencies (all inheritance, including indirect dependencies) of the Hello Project. Now every project that relies on our lib will get these configurations. You can also set the Public_configs to set to apply only to target projects that are directly dependent (not delivered).

Now, if you compile and run, you will see a new version of two people:

> ninja-c out/default say_hello
ninja:entering directory ' Out/default '
[1/1] Regenerating ninja Files
[ 4/4] LINK Say_hello
> Out/default/say_hello
Hello, Bill and Joy.

Add a new compilation parameter

You can directly declare the parameters you accept by Declare_args and specify their default values.

Declare_args () {
  Enable_teleporter = true
  Enable_doom_melon = False
}

Use GN help Buildargs to get an overview of how they work. Use GN help Declare_args to get the details of the declaration parameters.

It is an error to declare a given argument more than once in a given scope, so care should being used in scoping and naming a Rguments. don't know what's going on. (Don ' t know what's going on?)

You can run GN's verbose mode and you will see a lot of information about what is happening now. Enabled with-V. Print debugging Information

There is a print command that can be output to stdout:

Static_library ("Hello") {
  ...
  Print (configs)
}

This prints all the configuration information (including the default) that is applied to the target project. "desc" command

You can run GN Desc <build_dir> <targetname> Get the information for the specified target.

GN Desc Out/default//tools/gn/tutorial:say_hello

This will print out a lot of the information we want. You can also print only one item. Now tell you how to know where the Two_people macros in the target engineering Say_hello are defined:

> GN desc out/default//tools/gn/tutorial:say_hello defines--blame
... lots of other stuff omitted ...
  From//tools/gn/tutorial:hello_config
       (Added by//tools/gn/tutorial/build.gn:12)
    Two_people

You can see that the two_people is defined by a config, and you can also see where the config is applied to the target project (here, the All_dependent_configs line).

Two outside a particularly interesting command:

GN Desc Out/default//base:base_i18n Deps--tree

Refer to GN Help desc for details. Performance (performance)

Can see what took a long time by running it with the–time command line flag. This would output a summary of timings for various things.

You can also make a trace of how the build files were executed:

GN--tracelog=mylog.trace

And you can load the resulting file in Chrome's about:tracing page to look at everything.