Differences to Boost.Build V1

Configuration
Writing Jamfiles
Build process

While Boost.Build V2 is based on the same ideas as Boost.Build V1, some of the syntax was changed, and some new important fture in ss="term">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

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.