anchor.diff:  
   As far as configurations go, the main ones of interest are:
   
  + * `implementation` - used for compilation, linking and runtime
    * `cppCompile__Variant__` - for dependencies that are necessary to compile your production code but shouldn’t be part of the linking or runtime process
  - * `implementation` - used for compilation, linking and runtime
    * `nativeLink__Variant__` - for dependencies that are necessary to link your code but shouldn’t be part of the compilation or runtime process
    * `nativeRuntime__Variant__` - for dependencies that are necessary to run your component but shouldn’t be part of the compilation or linking process
   
  
positive.code: include::sample[dir="userguide/cpp/basic/kotlin",files="build.gradle.kts[tags=apply-cpp-plugin]"]
  ====
  
  By applying any of C++ plugin, you get a whole host of features:
  
   * A `compileDebugCpp` and `compileReleaseCpp` tasks that compiles the C++ source files under _src/main/cpp_ for the well-known debug and release build type respectively.
   * A `linkDebug` and `linkRelease` tasks that links the compiled C++ object files into an executable for applications or shared library for libraries with shared linkage for the well-known debug and release build type respectively.
   * A `createDebug` and `createRelease` tasks that assemble the compiled C++ object files into a static library for libraries with shared linkage for the well-known debug and release build type respectively
  
  This isn’t sufficient to build any non-trivial C++ project - at the very least, you’ll probably have some file dependencies.
  But it means that your build script only needs the information that is specific to _your_ project.
  
  // TODO: Add base plugin link
  The C++ plugins also integrate the above tasks into the standard Lifecycle Base Plugin lifecycle tasks:
  
   * `linkDebug` is attached to `assemble`
  
  The rest of the chapter explains the different avenues for customizing the build to your requirements. You will also see later how to adjust the build specifically for libraries and applications.
  
  == Introducing build variants
  
  Native projects can typically produce several different binaries, such as debug or release ones, or ones that target particular platforms and processor architectures.
  Gradle manages this through the concepts of _dimensions_ and _variants_.
  
  A dimension is simply a category, where each dimension is orthogonal to the rest.
  For example, the "build type" dimension is a category that includes debug and release builds.
  The "architecture" dimension covers processor architectures like x86_64 and PowerPC.
  
  A variant is a combination of values for these dimensions, consisting of exactly one value for each dimension.
  So based on the dimensions just mentioned, you might have a "debug x86_64" or a "release PowerPC" variant.
  
  Gradle has built-in support for several dimensions and several values within each dimension.
  You can find a list of them in the <<plugin_reference.adoc#native_languages,native plugin reference chapter>>.
  
negative.code: = Building C++ projects
  
  Gradle uses a convention-over-configuration approach to building native projects.
  If you are coming from another native build system, these concepts may be unfamiliar at first, but they serve a purpose to simplify build script authoring.
  
  We will look at C\++ projects in detail in this chapter, but most of the topics will apply to other supported native languages as well.
  If you don’t have much experience with building native projects with Gradle, take a look at the C++ tutorials for step-by-step instructions on how to build various types of basic C++ projects as well as some common use cases.
  
  The C++ plugins covered in this chapter were https://blog.gradle.org/introducing-the-new-cpp-plugins[introduced in 2018] and we recommend users to use those plugins over <<native_software.adoc#native_binaries,the older Native plugins>> that you may find references to.
  
  == Introduction
  
  