anchor.diff:  
   You can learn more about these and how they relate to one another in the native plugin reference chapter.
   
  -Be aware that the <<cpp_library_plugin.adoc#,C++ Library Plugin>> creates an additional configuration - `api` - for dependencies that are required for compiling and linking both the module and any modules that depend on it.
  -
  -We have only scratched the surface here, so we recommend that you read the dedicated dependency management chapters once you’re comfortable with the basics of building C++ projects with Gradle.
  +Be aware that the <<cpp_library_plugin.adoc#,{cpp} Library Plugin>> creates an additional configuration - `api` - for dependencies that are required for compiling and linking both the module and any modules that depend on it.
  +
  +We have only scratched the surface here, so we recommend that you read the dedicated dependency management chapters once you’re comfortable with the basics of building {cpp} projects with Gradle.
   
   Some common scenarios that require further reading include:
   
  
positive.code: [[sec:select_cpp_target_machines]]
  === Selecting target machines
  
  By default, Gradle will attempt to create a C++ binary variant for the host operating system and architecture.
  It is possible to override this by specifying the set of `TargetMachine` on the `application` or `library` script block:
  
  .Setting target machines
  
negative.code: [[sec:cleaning_cpp_build]]
  == Cleaning the build
  
  The {cpp} Application and Library Plugins add a `clean` task to you project by using the <<base_plugin,base plugin>>.
  This task simply deletes everything in the `$buildDir` directory, hence why you should always put files generated by the build in there.
  The task is an instance of Delete and you can change what directory it deletes by setting its `dir` property.
  
  [[sec:building_cpp_libraries]]
  == Building {cpp} libraries
  
  The unique aspect of library projects is that they are used (or "consumed") by other {cpp} projects.
  That means the dependency metadata published with the binaries and headers - in the form of a Gradle Metadata - is crucial.
  In particular, consumers of your library should be able to distinguish between two different types of dependencies: those that are only required to compile your library and those that are also required to compile the consumer.
  
  Gradle manages this distinction via the <<cpp_library_plugin.adoc#,{cpp} Library Plugin>>, which introduces an _api_ configuration in addition to the _implementation_ once covered in this chapter.
  If the types from a dependency appear as unresolved symbols of the static library or within the public headers then that dependency is exposed via your library’s public API and should, therefore, be added to the _api_ configuration.
  Otherwise, the dependency is an internal implementation detail and should be added to _implementation_.
  
  If you’re unsure of the difference between an API and implementation dependency, the <<cpp_library_plugin.adoc#sec:cpp_library_api_vs_implementation,{cpp} Library Plugin>> chapter has a detailed explanation.
  In addition, you can see a basic, practical example of building a {cpp} library in the corresponding link:{guidesUrl}/building-cpp-libraries[guide].
  
  [[sec:building_cpp_applications]]
  == Building {cpp} applications
  
  See the <<cpp_application_plugin.adoc#,{cpp} Application Plugin>> chapter for more details, but here’s a quick summary of what you get:
  
   * `install` create a directory containing everything needed to run it
   * Shell and Windows Batch scripts to start the application
  
  You can see a basic example of building a {cpp} application in the corresponding link:{guidesUrl}/building-cpp-applications[guide].
  