Builtin features

| Home | Libraries | People | FAQ | More

## Builtin features

`variant`

  The feature which combines several low-level features in order to make building most common variants simple.

  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 build to suit expectations of people used various IDEs. It's assumed other folks don't have any specific expectation in this point.

`link`

  Feature which controls how libraries are built.

  Allowed values:`shared`, `static`

`source`
  Tthe <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 it will be linked to all executables.
`library`
  This feature is equivalent to the <source> feature, and exists for backward compatibility reasons.
`use`
  Causes the target referenced by the value of this feature to be constructed and adds it's usage requirements to build properties. The constructed targets are not used in any other way. The primary use case is when you use some library and want it's usage requirements (such as include paths) to be applied, but don't want to link to the library.
`dll-path`
  Specify an additional path where shared libraries should be searched where the executable or shared library is run. This feature only affect Unix compilers. Plase see the FAQ entry 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 build 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.