| Home | Libraries | People | FAQ | More

## 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

  Rationale: Runtime debugging is on in debug builds to suit the expectations of people used to various IDEs. It's assumed other folks don't have any specific expectation in this point.

`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. The feature is sometimes more convenient: you can put `<source>X` in the requirements for a project and `X` will be included as a source in all of the project's main targets.
`library`
  This feature is equivalent to the <source> feature, and exists for backward compatibility reasons.
`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), 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.
`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 27, 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 C and C++ compilers, for `cxxflags` that's C++ compiler and for `linkflags` that's linker. The features are handy when you're trying to do something special that cannot be achieved by higher-level feature in Boost.Build.