## Builtin features

`variant`

  A feature that combines several low-level features, making it easy to request common build configurations.

  Allowed values: `debug`, `release`, `profile`.

  The value `debug` expands to

      <optimization>off <debug-symbols>on <inlining>off <runtime-debugging>on

  The value `release` expands to

      <optimization>speed <debug-symbols>off <inlining>full <runtime-debugging>off

  The value `profile` expands to the same as `release`, plus:

      <profiling>on <debug-symbols>on

  User can define his own build variants using the `variant` rule from the `common` module.

  Notee: Runtime debugging is on in debug builds to suit the expectations of people used to various IDEs.

`link`

  A feature that controls how libraries are built.

  Allowed values: `shared`, `static`

`source`
  The `<source>X` feature has the same effect on building a target as putting X in the list of sources. It's useful when you want to add the same source to all targets in the project (you can put <source> in requirements) or to conditionally include a source (using conditional requirements, see the section called “Conditions and alternatives”) See also the `<library>` feature.
`library`
  This feature is almost equivalent to the `<source>` feature, except that it takes effect only for linking. When you want to link all targets in a Jamfile to certain library, the `<library>` feature is preferred over `<source>X` -- the latter will add the library to all targets, even those that have nothing to do with libraries.
`dependency`
  Introduces a dependency on the target named by the value of this feature (so it will be brought up-to-date whenever the target being declared is). The dependency is not used in any other way. For example, in application with plugins, the plugins are not used when linking the application, application might have dependency on its plugins, even though , and adds its usage requirements to the build properties of the target being declared. The primary use case is when you want the usage requirements (such as `#include` paths) of some library to be applied, but don't want to link to it.
`use`
  Introduces a dependency on the target named by the value of this feature (so it will be brought up-to-date whenever the target being declared is), and adds its usage requirements to the build properties of the target being declared. The dependency is not used in any other way. The primary use case is when you want the usage requirements (such as `#include` paths) of some library to be applied, but don't want to link to it.
`dll-path`
  Specify an additional directory where the system should look for shared libraries when the executable or shared library is run. This feature only affects Unix compilers. Plase see the section called “Why are the `dll-path` and `hardcode-dll-paths` properties useful? ” in Chapter 8, Frequently Asked Questions for details.
`hardcode-dll-paths`

  Controls automatic generation of dll-path properties.

  Allowed values: `true`, `false`. This property is specific to Unix systems. If an executable is built with `<hardcode-dll-paths>true`, the generated binary will contain the list of all the paths to the used shared libraries. As the result, the executable can be run without changing system paths to shared libraries or installing the libraries to system paths. This is very convenient during development. Plase see the FAQ entry for details. Note that on Mac OSX, the paths are unconditionally hardcoded by the linker, and it's not possible to disable that behaviour.

`cflags`, `cxxflags`, `linkflags`
  The value of those features is passed without modification to the corresponding tools. For `cflags` that's both the C and C++ compilers, for `cxxflags` that's the C++ compiler and for `linkflags` that's the linker. The features are handy when you're trying to do something special that cannot be achieved by higher-level feature in Boost.Build.
`warnings`
  The `<warnings>` feature controls the warning level of compilers. It has the following values:

  - `off` - disables all warnings.

  - `on` - enables default warning level for the tool.

  - `all` - enables all warnings.

  Default value is `all`.
`warnings-as-errors`
  The `<warnings-as-errors>` makes it possible to treat warnings as errors and abort compilation on a warning. The value `on` enables this behaviour. The default value is `off`.
`build`

  Allowed values: `no`

  The `build` feature is used to conditionally disable build of a target. If `<build>no` is in properties when building a target, build of that target is skipped. Combined with conditional requirements this allows to skip building some target in configurations where the build is known to fail.

`tag`

  The `tag` feature is used to customize the name of the generated files. The value should have the form:

      @rulename

  where `rulename` should be a name of a rule with the following signature:

      rule tag ( name : type ? : property-set )

  The rule will be called for each target with the default name computed by Boost.Build, the type of the target, and property set. The rule can either return a string that must be used as the name of the target, or empty string, in which case the default name will be used.

  Most typical use of the `tag` feature is to encode build properties, or library version in library target names. You should take care to return non-empty string from the tag rule only for types you care about — otherwise, you might end up modifying names of object files, generated header file and other targets for which changing names does not make sense.

`debug-symbols`

  Allowed values: `on`, `off`.

  The `debug-symbols` feature specifies if produced object files, executables and libraries should include debug information. Typically, the value of this feature is implicitly set by the `variant` feature, but it can be explicitly specified by the user. The most common usage is to build release variant with debugging information.