Kargi-Sitesi/node_modules/node-gyp/gyp/docs/InputFormatReference.md

# Input Format Reference

## Primitive Types

The following primitive types are found within input files:

  * String values, which may be represented by enclosing them in
    `'single quotes'` or `"double quotes"`.  By convention, single
    quotes are used.
  * Integer values, which are represented in decimal without any special
    decoration.  Integers are fairly rare in input files, but have a few
    applications in boolean contexts, where the convention is to
    represent true values with `1` and false with `0`.
  * Lists, which are represented as a sequence of items separated by
    commas (`,`) within square brackets (`[` and `]`).  A list may
    contain any other primitive types, including other lists.
    Generally, each item of a list must be of the same type as all other
    items in the list, but in some cases (such as within `conditions`
    sections), the list structure is more tightly specified.  A trailing
    comma is permitted.

    This example list contains three string values.

      ```
      [ 'Generate', 'Your', 'Projects', ]
      ```

  * Dictionaries, which map keys to values.  All keys are strings.
    Values may be of any other primitive type, including other
    dictionaries.  A dictionary is enclosed within curly braces (`{` and
    `}`).  Keys precede values, separated by a colon (`:`).  Successive
    dictionary entries are separated by commas (`,`).  A trailing comma
    is permitted.  It is an error for keys to be duplicated within a
    single dictionary as written in an input file, although keys may
    replace other keys during [merging](#Merging).

    This example dictionary maps each of three keys to different values.

      ```
      {
        'inputs': ['version.c.in'],
        'outputs': ['version.c'],
        'process_outputs_as_sources': 1,
      }
      ```

## Overall Structure

A GYP input file is organized as structured data.  At the root scope of
each `.gyp` or `.gypi` (include) file is a dictionary.  The keys and
values of this dictionary, along with any descendants contained within
the values, provide the data contained within the file.  This data is
given meaning by interpreting specific key names and their associated
values in specific ways (see [Settings Keys](#Settings_Keys)).

### Comments (#)

Within an input file, a comment is introduced by a pound sign (`#`) not
within a string.  Any text following the pound sign, up until the end of
the line, is treated as a comment.

#### Example

```
{
  'school_supplies': [
    'Marble composition book',
    'Sharp #2 pencil',
    'Safety scissors',  # You still shouldn't run with these
  ],
}
```

In this example, the # in `'Sharp #2 pencil'` is not taken as
introducing a comment because it occurs within a string, but the text
after `'Safety scissors'` is treated as a comment having no impact on
the data within the file.

## Merging

### Merge Basics (=, ?, +)

Many operations on GYP input files occurs by merging dictionary and list
items together.  During merge operations, it is important to recognize
the distinction between source and destination values.  Items from the
source value are merged into the destination, which leaves the source
unchanged and the destination modified by the source.  A dictionary may
only be merged into another dictionary, and a list may only be merged
into another list.

  * When merging a dictionary, for each key in the source:
    * If the key does not exist in the destination dictionary, insert it
      and copy the associated value directly.
    * If the key does exist:
      * If the associated value is a dictionary, perform the dictionary
        merging procedure using the source's and destination's value
        dictionaries.
      * If the associated value is a list, perform the list merging
        procedure using the source's and destination's value lists.
      * If the associated value is a string or integer, the destination
        value is replaced by the source value.
  * When merging a list, merge according to the suffix appended to the
    key name, if the list is a value within a dictionary.
    * If the key ends with an equals sign (`=`), the policy is for the
      source list to completely replace the destination list if it
      exists.  _Mnemonic: `=` for assignment._
    * If the key ends with a question mark (`?`), the policy is for the
      source list to be set as the destination list only if the key is
      not already present in the destination.  _Mnemonic: `?` for
      conditional assignment_.
    * If the key ends with a plus sign (`+`), the policy is for the
      source list contents to be prepended to the destination list.
      _Mnemonic: `+` for addition or concatenation._
    * If the list key is undecorated, the policy is for the source list
      contents to be appended to the destination list.  This is the
      default list merge policy.

#### Example

Source dictionary:

```
{
  'include_dirs+': [
    'shared_stuff/public',
  ],
  'link_settings': {
    'libraries': [
      '-lshared_stuff',
    ],
  },
  'test': 1,
}
```

Destination dictionary:

```
{
  'target_name': 'hello',
  'sources': [
    'kitty.cc',
  ],
  'include_dirs': [
    'headers',
  ],
  'link_settings': {
    'libraries': [
      '-lm',
    ],
    'library_dirs': [
      '/usr/lib',
    ],
  },
  'test': 0,
}
```

Merged dictionary:

```
{
  'target_name': 'hello',
  'sources': [
    'kitty.cc',
  ],
  'include_dirs': [
    'shared_stuff/public',  # Merged, list item prepended due to include_dirs+
    'headers',
  ],
  'link_settings': {
    'libraries': [
      '-lm',
      '-lshared_stuff',  # Merged, list item appended
    ],
    'library_dirs': [
      '/usr/lib',
    ],
  },
  'test': 1,  # Merged, int value replaced
}
```

## Pathname Relativization

In a `.gyp` or `.gypi` file, many string values are treated as pathnames
relative to the file in which they are defined.

String values associated with the following keys, or contained within
lists associated with the following keys, are treated as pathnames:

  * destination
  * files
  * include\_dirs
  * inputs
  * libraries
  * outputs
  * sources
  * mac\_bundle\_resources
  * mac\_framework\_dirs
  * msvs\_cygwin\_dirs
  * msvs\_props

Additionally, string values associated with keys ending in the following
suffixes, or contained within lists associated with keys ending in the
following suffixes, are treated as pathnames:

  * `_dir`
  * `_dirs`
  * `_file`
  * `_files`
  * `_path`
  * `_paths`

However, any string value beginning with any of these characters is
excluded from pathname relativization:

  * `/` for identifying absolute paths.
  * `$` for introducing build system variable expansions.
  * `-` to support specifying such items as `-llib`, meaning “library
    `lib` in the library search path.”
  * `<`, `>`, and `!` for GYP expansions.

When merging such relative pathnames, they are adjusted so that they can
remain valid relative pathnames, despite being relative to a new home.

#### Example

Source dictionary from `../build/common.gypi`:

```
{
  'include_dirs': ['include'],  # Treated as relative to ../build
  'libraries': ['-lz'],  # Not treated as a pathname, begins with a dash
  'defines': ['NDEBUG'],  # defines does not contain pathnames
}
```

Target dictionary, from `base.gyp`:

```
{
  'sources': ['string_util.cc'],
}
```

Merged dictionary:

```
{
  'sources': ['string_util.cc'],
  'include_dirs': ['../build/include'],
  'libraries': ['-lz'],
  'defines': ['NDEBUG'],
}
```

Because of pathname relativization, after the merge is complete, all of
the pathnames in the merged dictionary are valid relative to the
directory containing `base.gyp`.

## List Singletons

Some list items are treated as singletons, and the list merge process
will enforce special rules when merging them.  At present, any string
item in a list that does not begin with a dash (`-`) is treated as a
singleton, although **this is subject to change.**  When appending or
prepending a singleton to a list, if the item is already in the list,
only the earlier instance is retained in the merged list.

#### Example

Source dictionary:

```
{
  'defines': [
    'EXPERIMENT=1',
    'NDEBUG',
  ],
}
```

Destination dictionary:

```
{
  'defines': [
    'NDEBUG',
    'USE_THREADS',
  ],
}
```

Merged dictionary:

```
{
  'defines': [
    'NDEBUG',
    'USE_THREADS',
    'EXPERIMENT=1',  # Note that NDEBUG is not appended after this.
  ],
}
```

## Including Other Files

If the `-I` (`--include`) argument was used to invoke GYP, any files
specified will be implicitly merged into the root dictionary of all
`.gyp` files.

An [includes](#includes) section may be placed anywhere within a
`.gyp` or `.gypi` (include) file.  `includes` sections contain lists of
other files to include.  They are processed sequentially and merged into
the enclosing dictionary at the point that the `includes` section was
found.  `includes` sections at the root of a `.gyp` file dictionary are
merged after any `-I` includes from the command line.

[includes](#includes) sections are processed immediately after a file is
loaded, even before [variable and conditional
processing](#Variables_and_Conditionals), so it is not possible to
include a file based on a [variable reference](#Variable_Expansions).
While it would be useful to be able to include files based on variable
expansions, it is most likely more useful to allow included files access
to variables set by the files that included them.

An [includes](#includes) section may, however, be placed within a
[conditional](#Conditionals) section.  The included file itself will
be loaded unconditionally, but its dictionary will be discarded if the
associated condition is not true.

## Variables and Conditionals

### Variables

There are three main types of variables within GYP.

  * Predefined variables.  By convention, these are named with
    `CAPITAL_LETTERS`.  Predefined variables are set automatically by
    GYP.  They may be overridden, but it is not advisable to do so.  See
    [Predefined Variables](#Predefined_Variables) for a list of
    variables that GYP provides.
  * User-defined variables.  Within any dictionary, a key named
    `variables` can be provided, containing a mapping between variable
    names (keys) and their contents (values), which may be strings,
    integers, or lists of strings.  By convention, user-defined
    variables are named with `lowercase_letters`.
  * Automatic variables.  Within any dictionary, any key with a string
    value has a corresponding automatic variable whose name is the same
    as the key name with an underscore (`_`) prefixed.  For example, if
    your dictionary contains `type: 'static_library'`, an automatic
    variable named `_type` will be provided, and its value will be a
    string, `'static_library'`.

Variables are inherited from enclosing scopes.

### Providing Default Values for Variables (%)

Within a `variables` section, keys named with percent sign (`%`)
suffixes mean that the variable should be set only if it is undefined at
the time it is processed.  This can be used to provide defaults for
variables that would otherwise be undefined, so that they may reliably
be used in [variable expansion or conditional
processing](#Variables_and_Conditionals).

### Predefined Variables

Each GYP generator module provides defaults for the following variables:

  * `OS`: The name of the operating system that the generator produces
    output for.  Common values for values for `OS` are:

    * `'linux'`
    * `'mac'`
    * `'win'`

    But other values may be encountered and this list should not be
    considered exhaustive.  The `gypd` (debug) generator module does not
    provide a predefined value for `OS`.  When invoking GYP with the
    `gypd` module, if a value for `OS` is needed, it must be provided on
    the command line, such as `gyp -f gypd -DOS=mac`.

    GYP generators also provide defaults for these variables.  They may
    be expressed in terms of variables used by the build system that
    they generate for, often in `$(VARIABLE)` format.  For example, the
    GYP `PRODUCT_DIR` variable maps to the Xcode `BUILT_PRODUCTS_DIR`
    variable, so `PRODUCT_DIR` is defined by the Xcode generator as
    `$(BUILT_PRODUCTS_DIR)`.
  * `EXECUTABLE_PREFIX`: A prefix, if any, applied to executable names.
    Usually this will be an empty string.
  * `EXECUTABLE_SUFFIX`: A suffix, if any, applied to executable names.
    On Windows, this will be `.exe`, elsewhere, it will usually be an
    empty string.
  * `INTERMEDIATE_DIR`: A directory that can be used to place
    intermediate build results in.  `INTERMEDIATE_DIR` is only
    guaranteed to be accessible within a single target (See targets).
    This variable is most useful within the context of rules and actions
    (See rules, See actions).  Compare with `SHARED_INTERMEDIATE_DIR`.
  * `PRODUCT_DIR`: The directory in which the primary output of each
    target, such as executables and libraries, is placed.
  * `RULE_INPUT_ROOT`: The base name for the input file (e.g. "`foo`").
    See Rules.
  * `RULE_INPUT_EXT`: The file extension for the input file (e.g.
    "`.cc`").  See Rules.
  * `RULE_INPUT_NAME`: Full name of the input file (e.g. "`foo.cc`").
    See Rules.
  * `RULE_INPUT_PATH`: Full path to the input file (e.g.
    "`/bar/foo.cc`").  See Rules.
  * `SHARED_INTERMEDIATE_DIR`: A directory that can be used to place
    intermediate build results in, and have them be accessible to other
    targets.  Unlike `INTERMEDIATE_DIR`, each target in a project,
    possibly spanning multiple `.gyp` files, shares the same
    `SHARED_INTERMEDIATE_DIR`.

The following additional predefined variables may be available under
certain circumstances:

  * `DEPTH`.  When GYP is invoked with a `--depth` argument, when
    processing any `.gyp` file, `DEPTH` will be a relative path from the
    `.gyp` file to the directory specified by the `--depth` argument.

### User-Defined Variables

A user-defined variable may be defined in terms of other variables, but
not other variables that have definitions provided in the same scope.

### Variable Expansions (<, >, <@, >@)

GYP provides two forms of variable expansions, “early” or “pre”
expansions, and “late,” “post,” or “target” expansions.  They have
similar syntax, differing only in the character used to introduce them.

  * Early expansions are introduced by a less-than (`<`) character.
    _Mnemonic: the arrow points to the left, earlier on a timeline._
  * Late expansions are introduced by a less-than (`>`) character.
    _Mnemonic: the arrow points to the right, later on a timeline._

The difference the two phases of expansion is described in [Early and
Late Phases](#Early_and_Late_Phases).

These characters were chosen based upon the requirement that they not
conflict with the variable format used natively by build systems.  While
the dollar sign (`$`) is the most natural fit for variable expansions,
its use was ruled out because most build systems already use that
character for their own variable expansions.  Using different characters
means that no escaping mechanism was needed to differentiate between GYP
variables and build system variables, and writing build system variables
into GYP files is not cumbersome.

Variables may contain lists or strings, and variable expansions may
occur in list or string context.  There are variant forms of variable
expansions that may be used to determine how each type of variable is to
be expanded in each context.

  * When a variable is referenced by `<(VAR)` or `>(VAR)`:
    * If `VAR` is a string, the variable reference within the string is
      replaced by variable's string value.
    * If `VAR` is a list, the variable reference within the string is
      replaced by a string containing the concatenation of all of the
      variable’s list items.  Generally, the items are joined with
      spaces between each, but the specific behavior is
      generator-specific.  The precise encoding used by any generator
      should be one that would allow each list item to be treated as a
      separate argument when used as program arguments on the system
      that the generator produces output for.
  * When a variable is referenced by `<@(VAR)` or `>@(VAR)`:
    * The expansion must occur in list context.
    * The list item must be `'<@(VAR)'` or `'>@(VAR)'` exactly.
    * If `VAR` is a list, each of its elements are inserted into the
      list in which expansion is taking place, replacing the list item
      containing the variable reference.
    * If `VAR` is a string, the string is converted to a list which is
      inserted into the list in which expansion is taking place as
      above.  The conversion into a list is generator-specific, but
      generally, spaces in the string are taken as separators between
      list items.  The specific method of converting the string to a
      list should be the inverse of the encoding method used to expand
      list variables in string context, above.

GYP treats references to undefined variables as errors.

### Command Expansions (<!, <!@)

Command expansions function similarly to variable expansions, but
instead of resolving variable references, they cause GYP to execute a
command at generation time and use the command’s output as the
replacement.  Command expansions are introduced by a less than and
exclamation mark (`<!`).

In a command expansion, the entire string contained within the
parentheses is passed to the system’s shell.  The command’s output is
assigned to a string value that may subsequently be expanded in list
context in the same way as variable expansions if an `@` character is
used.

In addition, command expansions (unlike other variable expansions) may
include nested variable expansions.  So something like this is allowed:

```
'variables' : [
  'foo': '<!(echo Build Date <!(date))',
],
```

expands to:

```
'variables' : [
  'foo': 'Build Date 02:10:38 PM Fri Jul 24, 2009 -0700 PDT',
],
```

You may also put commands into arrays in order to quote arguments (but
note that you need to use a different string quoting character):

```
'variables' : [
  'files': '<!(["ls", "-1", "Filename With Spaces"])',
],
```

GYP treats command failures (as indicated by a nonzero exit status)
during command expansion as errors.

#### Example

```
{
  'sources': [
    '!(echo filename with space.cc)',
  ],
  'libraries': [
    '!@(pkg-config --libs-only-l apr-1)',
  ],
}
```

might expand to:

```
{
  'sources': [
    'filename with space.cc',  # no @, expands into a single string
  ],
  'libraries': [  # @ was used, so there's a separate list item for each lib
    '-lapr-1',
    '-lpthread',
  ],
}
```

## Conditionals

Conditionals use the same set of variables used for variable expansion.
As with variable expansion, there are two phases of conditional
evaluation:

  * “Early” or “pre” conditional evaluation, introduced in
    [conditions](#conditions) sections.
  * “Late,” “post,” or “target” conditional evaluation, introduced in
    [target\_conditions](#target_conditions) sections.

The syntax for each type is identical, they differ only in the key name
used to identify them and the timing of their evaluation.  A more
complete description of syntax and use is provided in
[conditions](#conditions).

The difference the two phases of evaluation is described in [Early and
Late Phases](#Early_and_Late_Phases).

## Timing of Variable Expansion and Conditional Evaluation

### Early and Late Phases

GYP performs two phases of variable expansion and conditional evaluation:

  * The “early” or “pre” phase operates on [conditions](#conditions)
    sections and the `<` form of [variable
    expansions](#Variable_Expansions).
  * The “late,” “post,” or “target” phase operates on
    [target\_conditions](#target_conditions) sections, the `>` form
    of [variable expansions](#Variable_Expansions),
    and on the `!` form of [command
    expansions](#Command_Expansions_(!,_!@)).

These two phases are provided because there are some circumstances in
which each is desirable.

The “early” phase is appropriate for most expansions and evaluations.
“Early” expansions and evaluations may be performed anywhere within any
`.gyp` or `.gypi` file.

The “late” phase is appropriate when expansion or evaluation must be
deferred until a specific section has been merged into target context.
“Late” expansions and evaluations only occur within `targets` sections
and their descendants.  The typical use case for a late-phase expansion
is to provide, in some globally-included `.gypi` file, distinct
behaviors depending on the specifics of a target.

#### Example

Given this input:

```
{
  'target_defaults': {
    'target_conditions': [
      ['_type=="shared_library"', {'cflags': ['-fPIC']}],
    ],
  },
  'targets': [
    {
      'target_name': 'sharing_is_caring',
      'type': 'shared_library',
    },
    {
      'target_name': 'static_in_the_attic',
      'type': 'static_library',
    },
  ]
}
```

The conditional needs to be evaluated only in target context; it is
nonsense outside of target context because no `_type` variable is
defined.  [target\_conditions](#target_conditions) allows evaluation
to be deferred until after the [targets](#targets) sections are
merged into their copies of [target\_defaults](#target_defaults).
The resulting targets, after “late” phase processing:

```
{
  'targets': [
    {
      'target_name': 'sharing_is_caring',
      'type': 'shared_library',
      'cflags': ['-fPIC'],
    },
    {
      'target_name': 'static_in_the_attic',
      'type': 'static_library',
    },
  ]
}
```

### Expansion and Evaluation Performed Simultaneously

During any expansion and evaluation phase, both expansion and evaluation
are performed simultaneously.  The process for handling variable
expansions and conditional evaluation within a dictionary is:

  * Load [automatic variables](#Variables) (those with leading
    underscores).
  * If a [variables](#variables) section is present, recurse into its
    dictionary.  This allows [conditionals](#Conditionals) to be
    present within the `variables` dictionary.
  * Load [Variables user-defined variables](#User-Defined) from the
    [variables](#variables) section.
  * For each string value in the dictionary, perform [variable
    expansion](#Variable_Expansions) and, if operating
    during the “late” phase, [command
    expansions](#Command_Expansions).
  * Reload [automatic variables](#Variables) and [Variables
    user-defined variables](#User-Defined) because the variable
    expansion step may have resulted in changes to the automatic
    variables.
  * If a [conditions](#conditions) or
    [target\_conditions](#target_conditions) section (depending on
    phase) is present, recurse into its dictionary.  This is done after
    variable expansion so that conditionals may take advantage of
    expanded automatic variables.
  * Evaluate [conditionals](#Conditionals).
  * Reload [automatic variables](#Variables) and [Variables
    user-defined variables](#User-Defined) because the conditional
    evaluation step may have resulted in changes to the automatic
    variables.
  * Recurse into child dictionaries or lists that have not yet been
    processed.

One quirk of this ordering is that you cannot expect a
[variables](#variables) section within a dictionary’s
[conditional](#Conditionals) to be effective in the dictionary
itself, but the added variables will be effective in any child
dictionaries or lists.  It is thought to be far more worthwhile to
provide resolved [automatic variables](#Variables) to
[conditional](#Conditionals) sections, though.  As a workaround, to
conditionalize variable values, place a [conditions](#conditions) or
[target\_conditions](#target_conditions) section within the
[variables](#variables) section.

## Dependencies and Dependents

In GYP, “dependents” are targets that rely on other targets, called
“dependencies.”  Dependents declare their reliance with a special
section within their target dictionary,
[dependencies](#dependencies).

### Dependent Settings

It is useful for targets to “advertise” settings to their dependents.
For example, a target might require that all of its dependents add
certain directories to their include paths, link against special
libraries, or define certain preprocessor macros.  GYP allows these
cases to be handled gracefully with “dependent settings” sections.
There are three types of such sections:

  * [direct\_dependent\_settings](#direct_dependent_settings), which
    advertises settings to a target's direct dependents only.
  * [all\_dependent\_settings](#all_dependnet_settings), which
    advertises settings to all of a target's dependents, both direct and
    indirect.
  * [link\_settings](#link_settings), which contains settings that
    should be applied when a target’s object files are used as linker
    input.

Furthermore, in some cases, a target needs to pass its dependencies’
settings on to its own dependents.  This might happen when a target’s
own public header files include header files provided by its dependency.
[export\_dependent\_settings](#export_dependent_settings) allows a
target to declare dependencies for which
[direct\_dependent\_settings](#direct_dependent_settings) should be
passed through to its own dependents.

Dependent settings processing merges a copy of the relevant dependent
settings dictionary from a dependency into its relevant dependent
targets.

In most instances,
[direct\_dependent\_settings](#direct_dependent_settings) will be
used.  There are very few cases where
[all\_dependent\_settings](#all_dependent_settings) is actually
correct; in most of the cases where it is tempting to use, it would be
preferable to declare
[export\_dependent\_settings](#export_dependent_settings).  Most
[libraries](#libraries) and [library\_dirs](#library_dirs)
sections should be placed within [link\_settings](#link_settings)
sections.

#### Example

Given:

```
{
  'targets': [
    {
      'target_name': 'cruncher',
      'type': 'static_library',
      'sources': ['cruncher.cc'],
      'direct_dependent_settings': {
        'include_dirs': ['.'],  # dependents need to find cruncher.h.
      },
      'link_settings': {
        'libraries': ['-lm'],  # cruncher.cc does math.
      },
    },
    {
      'target_name': 'cruncher_test',
      'type': 'executable',
      'dependencies': ['cruncher'],
      'sources': ['cruncher_test.cc'],
    },
  ],
}
```

After dependent settings processing, the dictionary for `cruncher_test`
will be:

```
{
  'target_name': 'cruncher_test',
  'type': 'executable',
  'dependencies': ['cruncher'],  # implies linking against cruncher
  'sources': ['cruncher_test.cc'],
  'include_dirs': ['.']
  'libraries': ['-lm'],
},
```

If `cruncher` was declared as a `shared_library` instead of a
`static_library`, the `cruncher_test` target would not contain `-lm`,
but instead, `cruncher` itself would link against `-lm`.

## Linking Dependencies

The precise meaning of a dependency relationship varies with the
[types](#type) of the [targets](#targets) at either end of the
relationship.  In GYP, a dependency relationship can indicate two things
about how targets relate to each other:

  * Whether the dependent target needs to link against the dependency.
  * Whether the dependency target needs to be built prior to the
    dependent.  If the former case is true, this case must be true as
    well.

The analysis of the first item is complicated by the differences between
static and shared libraries.

  * Static libraries are simply collections of object files (`.o` or
    `.obj`) that are used as inputs to a linker (`ld` or `link.exe`).
    Static libraries don't link against other libraries, they’re
    collected together and used when eventually linking a shared library
    or executable.
  * Shared libraries are linker output and must undergo symbol
    resolution.  They must link against other libraries (static or
    shared) in order to facilitate symbol resolution.  They may be used
    as libraries in subsequent link steps.
  * Executables are also linker output, and also undergo symbol
    resolution.  Like shared libraries, they must link against static
    and shared libraries to facilitate symbol resolution.  They may not
    be reused as linker inputs in subsequent link steps.

Accordingly, GYP performs an operation referred to as “static library
dependency adjustment,” in which it makes each linker output target
(shared libraries and executables) link against the static libraries it
depends on, either directly or indirectly.  Because the linkable targets
link against these static libraries, they are also made direct
dependents of the static libraries.

As part of this process, GYP is also able to remove the direct
dependency relationships between two static library targets, as a
dependent static library does not actually need to link against a
dependency static library.  This removal facilitates speedier builds
under some build systems, as they are now free to build the two targets
in parallel.  The removal of this dependency is incorrect in some cases,
such as when the dependency target contains [rules](#rules) or
[actions](#actions) that generate header files required by the
dependent target.  In such cases, the dependency target, the one
providing the side-effect files, must declare itself as a
[hard\_dependency](#hard_dependency).  This setting instructs GYP to
not remove the dependency link between two static library targets in its
generated output.

## Loading Files to Resolve Dependencies

When GYP runs, it loads all `.gyp` files needed to resolve dependencies
found in [dependencies](#dependencies) sections.  These files are not
merged into the files that reference them, but they may contain special
sections that are merged into dependent target dictionaries.

## Build Configurations

Explain this.

## List Filters

GYP allows list items to be filtered by “exclusions” and “patterns.”
Any list containing string values in a dictionary may have this
filtering applied.  For the purposes of this section, a list modified by
exclusions or patterns is referred to as a “base list”, in contrast to
the “exclusion list” and “pattern list” that operates on it.

  * For a base list identified by key name `key`, the `key!` list
    provides exclusions.
  * For a base list identified by key name `key`, the `key/` list
    provides regular expression pattern-based filtering.

Both `key!` and `key/` may be present.  The `key!` exclusion list will
be processed first, followed by the `key/` pattern list.

Exclusion lists are most powerful when used in conjunction with
[conditionals](#Conditionals).

## Exclusion Lists (!)

An exclusion list provides a way to remove items from the related list
based on exact matching.  Any item found in an exclusion list will be
removed from the corresponding base list.

#### Example

This example excludes files from the `sources` based on the setting of
the `OS` variable.

```
{
  'sources:' [
    'mac_util.mm',
    'win_util.cc',
  ],
  'conditions': [
    ['OS=="mac"', {'sources!': ['win_util.cc']}],
    ['OS=="win"', {'sources!': ['mac_util.cc']}],
  ],
}
```

## Pattern Lists (/)

Pattern lists are similar to, but more powerful than, [exclusion
lists](#Exclusion_Lists_(!)).  Each item in a pattern list is itself
a two-element list.  The first item is a string, either `'include'` or
`'exclude'`, specifying the action to take.  The second item is a string
specifying a regular expression.  Any item in the base list matching the
regular expression pattern will either be included or excluded, based on
the action specified.

Items in a pattern list are processed in sequence, and an excluded item
that is later included will not be removed from the list (unless it is
subsequently excluded again.)

Pattern lists are processed after [exclusion
lists](#Exclusion_Lists_(!)), so it is possible for a pattern list to
re-include items previously excluded by an exclusion list.

Nothing is actually removed from a base list until all items in an
[exclusion list](#Exclusion_Lists_(!)) and pattern list have been
evaluated.  This allows items to retain their correct position relative
to one another even after being excluded and subsequently included.

#### Example

In this example, a uniform naming scheme is adopted for
platform-specific files.

```
{
  'sources': [
    'io_posix.cc',
    'io_win.cc',
    'launcher_mac.cc',
    'main.cc',
    'platform_util_linux.cc',
    'platform_util_mac.mm',
  ],
  'sources/': [
    ['exclude', '_win\\.cc$'],
  ],
  'conditions': [
    ['OS!="linux"', {'sources/': [['exclude', '_linux\\.cc$']]}],
    ['OS!="mac"', {'sources/': [['exclude', '_mac\\.cc|mm?$']]}],
    ['OS=="win"', {'sources/': [
      ['include', '_win\\.cc$'],
      ['exclude', '_posix\\.cc$'],
    ]}],
  ],
}
```

After the pattern list is applied, `sources` will have the following
values, depending on the setting of `OS`:

  * When `OS` is `linux`: `['io_posix.cc', 'main.cc',
    'platform_util_linux.cc']`
  * When `OS` is `mac`: `['io_posix.cc', 'launcher_mac.cc', 'main.cc',
    'platform_util_mac.mm']`
  * When `OS` is `win`: `['io_win.cc', 'main.cc',
    'platform_util_win.cc']`

Note that when `OS` is `win`, the `include` for `_win.cc` files is
processed after the `exclude` matching the same pattern, because the
`sources/` list participates in [merging](#Merging) during
[conditional evaluation](#Conditonals) just like any other list
would.  This guarantees that the `_win.cc` files, previously
unconditionally excluded, will be re-included when `OS` is `win`.

## Locating Excluded Items

In some cases, a GYP generator needs to access to items that were
excluded by an [exclusion list](#Exclusion_Lists_(!)) or [pattern
list](#Pattern_Lists_(/)).  When GYP excludes items during processing
of either of these list types, it places the results in an `_excluded`
list.  In the example above, when `OS` is `mac`, `sources_excluded`
would be set to `['io_win.cc', 'platform_util_linux.cc']`.  Some GYP
generators use this feature to display excluded files in the project
files they generate for the convenience of users, who may wish to refer
to other implementations.

## Processing Order

GYP uses a defined and predictable order to execute the various steps
performed between loading files and generating output.

  * Load files.
    * Load `.gyp` files.  Merge any [command-line
      includes](#Including_Other_Files) into each `.gyp` file’s root
      dictionary.  As [includes](#Including_Other_Files) are found,
      load them as well and [merge](#Merging) them into the scope in
      which the [includes](#includes) section was found.
    * Perform [“early” or “pre”](#Early_and_Late_Phases) [variable
      expansion and conditional
      evaluation](#Variables_and_Conditionals).
    * [Merge](#Merging) each [target’s](#targets) dictionary into
      the `.gyp` file’s root [target\_defaults](#target_defaults)
      dictionary.
    * Scan each [target](#targets) for
      [dependencies](#dependencies), and repeat the above steps for
      any newly-referenced `.gyp` files not yet loaded.
  * Scan each [target](#targets) for wildcard
    [dependencies](#dependencies), expanding the wildcards.
  * Process [dependent settings](#Dependent_Settings).  These
    sections are processed, in order:
    * [all\_dependent\_settings](#all_dependent_settings)
    * [direct\_dependent\_settings](#direct_dependent_settings)
    * [link\_dependent\_settings](#link_dependent_settings)
  * Perform [static library dependency
    adjustment](#Linking_Dependencies).
  * Perform [“late,” “post,” or “target”](#Early_and_Late_Phases)
    [variable expansion and conditional
    evaluation](#Variables_and_Conditionals) on [target](#targets)
    dictionaries.
  * Merge [target](#targets) settings into
    [configurations](#configurations) as appropriate.
  * Process [exclusion and pattern
    lists](#List_Exclusions_and_Patterns).

## Settings Keys

### Settings that may appear anywhere

#### conditions

_List of `condition` items_

A `conditions` section introduces a subdictionary that is only merged
into the enclosing scope based on the evaluation of a conditional
expression.  Each `condition` within a `conditions` list is itself a
list of at least two items:

  1. A string containing the conditional expression itself.  Conditional
  expressions may take the following forms:
    * For string values, `var=="value"` and `var!="value"` to test
      equality and inequality.  For example, `'OS=="linux"'` is true
      when the `OS` variable is set to `"linux"`.
    * For integer values, `var==value`, `var!=value`, `var<value`,
      `var<=value`, `var>=value`, and `var>value`, to test equality and
      several common forms of inequality.  For example,
      `'chromium_code==0'` is true when the `chromium_code` variable is
      set to `0`.
    * It is an error for a conditional expression to reference any
      undefined variable.
  1. A dictionary containing the subdictionary to be merged into the
  enclosing scope if the conditional expression evaluates to true.

These two items can be followed by any number of similar two items that
will be evaluated if the previous conditional expression does not
evaluate to true.

An additional optional dictionary can be appended to this sequence of
two items.  This optional dictionary will be merged into the enclosing
scope if none of the conditional expressions evaluate to true.

Within a `conditions` section, each item is processed sequentially, so
it is possible to predict the order in which operations will occur.

There is no restriction on nesting `conditions` sections.

`conditions` sections are very similar to `target_conditions` sections.
See target\_conditions.

#### Example

```
{
  'sources': [
    'common.cc',
  ],
  'conditions': [
    ['OS=="mac"', {'sources': ['mac_util.mm']}],
    ['OS=="win"', {'sources': ['win_main.cc']}, {'sources': ['posix_main.cc']}],
    ['OS=="mac"', {'sources': ['mac_impl.mm']},
     'OS=="win"', {'sources': ['win_impl.cc']},
     {'sources': ['default_impl.cc']}
    ],
  ],
}
```

Given this input, the `sources` list will take on different values based
on the `OS` variable.

  * If `OS` is `"mac"`, `sources` will contain `['common.cc',
    'mac_util.mm', 'posix_main.cc', 'mac_impl.mm']`.
  * If `OS` is `"win"`, `sources` will contain `['common.cc',
    'win_main.cc', 'win_impl.cc']`.
  * If `OS` is any other value such as `"linux"`, `sources` will contain
    `['common.cc', 'posix_main.cc', 'default_impl.cc']`.