# C++ Library

version 8.14.3-20250906041242+0000

The C++ Library Plugin provides the tasks, conventions and conventions for building a C++ library. In particular, a C++ library provides functionality that can be used by consumers (i.e., other projects using this plugin or the C++ Application Plugin).

## Usage

Example 1. Applying the C++ Library Plugin
build.gradle.kts

    plugins {
        `cpp-library`
    }

build.gradle

    plugins {
        id 'cpp-library'
    }

## Build variants

The C++ Library Plugin understands the following dimensions. Read the introduction to build variants for more information.

Build types - always set to debug and release

  The build type controls the debuggability as well as the optimization of the generated binaries.

  - `debug` - Generate debug symbols and don’t optimized the binary

  - `release` - Generate debug symbols and optimize, but extract the debug symbols from the binary

Linkages - default to shared

  The linkage expresses whether a shared library or static library should be created. Libraries can produce a shared library, a static library or both.

The linkage can be configured as follows:

Example 2. Configure library linkages
build.gradle.kts

    library {
        linkage = listOf(Linkage.STATIC, Linkage.SHARED)
    }

build.gradle

    library {
        linkage = [Linkage.STATIC, Linkage.SHARED]
    }

Target machines - defaults to the build host

  The target machine expresses which machines the application expects to run. A target machine is identified by its operating system and architecture. Gradle uses the target machine to decide which tool chain to choose based on availability on the host machine.

The target machine can be configured as follows:

Example 3. Configure library target machines
build.gradle.kts

    library {
        targetMachines = listOf(machines.linux.x86_64,
            machines.windows.x86, machines.windows.x86_64,
            machines.macOS.x86_64)
    }

build.gradle

    library {
        targetMachines = [
            machines.linux.x86_64,
            machines.windows.x86, machines.windows.x86_64,
            machines.macOS.x86_64
        ]
    }

## Tasks

The following diagram shows the relationships between tasks added by this plugin.

Note the default linkage of a C++ library is shared linkage as shown in the diagram.

Figure 1. C++ Library Plugin default task graph

With static linkage, the diagram changes to the following:

Figure 2. C++ Library Plugin static library only task graph

### Variant-dependent Tasks

The C++ Library Plugin creates tasks based on variants of the library component. Read the introduction to build variants for more information. The following diagrams show the relationship between variant-dependent tasks.

Figure 3. C++ Library Plugin variant-dependent task graph

| Depending on the linkage property

`compileVariantCpp` (e.g. `compileDebugCpp` and `compileReleaseCpp`) - CppCompile

  Depends on: All tasks that contribute source files to the compilation :: Compiles C++ source files using the selected compiler.

`linkVariant` (e.g. `linkDebug` and `linkRelease`) - LinkSharedLibrary (shared linkage)

  Depends on: All tasks which contribute to the link libraries, including `linkVariant` and `createVariant` tasks from projects that are resolved via project dependencies :: Links shared library from compiled object files using the selected linker.

`createVariant` (e.g. `createDebug` and `createRelease`) - CreateStaticLibrary (static linkage)

  Creates static library from compiled object files using selected archiver

`assembleVariant` (e.g. `assembleDebug` and `assembleRelease`) - Task (lifecycle)

  Depends on: `linkVariant` (shared linkage) or `createVariant` (static linkage) :: Aggregates tasks that assemble the specific variant of this library.

### Lifecycle Tasks

The C++ Library Plugin attaches some of its tasks to the standard lifecycle tasks documented in the Base Plugin chapter — which the C++ Library Plugin applies automatically:

`assemble` - Task (lifecycle)

  Depends on: `linkDebug` when linkage includes `shared` or `createDebug` otherwise. :: Aggregate task that assembles the debug variant of the shared library (if available) for the current host (if present) in the project. This task is added by the Base Plugin.

`check` - Task (lifecycle)

  Aggregate task that performs verification tasks, such as running the tests. Some plugins add their own verification task to `check`. For example, the C++ Unit Test Plugin attach its test task to this lifecycle task. This task is added by the Base Plugin.

`build` - Task (lifecycle)

  Depends on: `check`, `assemble` :: Aggregate tasks that perform a full build of the project. This task is added by the Base Plugin.

`clean` - Delete

  Deletes the build directory and everything in it, i.e. the path specified by the `layout.buildDirectory` project property. This task is added by the Base Plugin.

## Dependency management

Just like the tasks created by the C++ Library Plugin, multiple configurations are created based on the variants of the library component. Read the introduction to build variants for more information. The following graph describes the configurations added by the C++ Library Plugin:

Figure 4. C++ Library Plugin configurations

- The configurations in white are the ones a user should use to declare dependencies

- The configurations in pink, also known as consumable denoted by (C), are the ones used when a component compiles, links, or runs against the library

- The configurations in blue, also known as resolvable denoted by (R), are internal to the component, for its own use

The following configurations are used to declare dependencies:

`api`

  Used for declaring API dependencies (see API vs implementation section). This is where you should declare dependencies which are transitively exported to consumers, for compile and link.

`implementation` extends `api`

  Used for declaring implementation dependencies for all variants of the main component (see API vs implementation section). This is where you should declare dependencies which are purely internal and not meant to be exposed to consumers of any variants.

`mainVariantImplementation` (e.g. `mainDebugImplementation` and `mainReleaseImplementation`) extends `implementation`

  Used for declaring implementation dependencies for a specific variant of the main component (see API vs implementation section). This is where you should declare dependencies which are purely internal and not meant to be exposed to consumers of this specific variant.

The following configurations are used by consumers:

`cppApiElements` extends `mainVariantImplementation`

  Used for compiling against the library. This configuration is meant to be used by consumers, to retrieve all the elements necessary to compile against the library.

`variantLinkElements` (e.g. `debugLinkElements` and `releaseLinkElements`) extends `mainVariantImplementation`

  Used for linking against the library. This configuration is meant to be used by consumers, to retrieve all the elements necessary to link against the library.

`variantRuntimeElements` (e.g. `debugRuntimeElements` and `releaseRuntimeElements) extends `mainVariantImplementation`

  Used for executing the library. This configuration is meant to be used by consumers, to retrieve all the elements necessary to run against the library.

The following configurations are used by the library itself:

`cppCompileVariant` (e.g. `cppCompileDebug` and `cppCompileRelease`) extends `mainVariantImplementation`

  Used for compiling the library. This configuration contains the compile include roots of the library and is therefore used when invoking the C++ compiler to compile it.

`nativeLinkVariant` (e.g. `nativeLinkDebug` and `nativeLinkRelease`) extends `mainVariantImplementation`

  Used for linking the library the shared library only. This configuration contains the libraries of the library and is therefore used when invoking the C++ linker to link it.

`nativeRuntimeVariant` (e.g. `nativeRuntimeDebug` and `nativeRuntimeRelease`) extends `mainVariantImplementation`

  Used for executing the library. This configuration contains the runtime libraries of the library.

### API vs implementation

The plugin exposes two configurations that can be used to declare dependencies: `api` and `implementation`. The `api` configuration should be used to declare dependencies which are exported by the library API, whereas the `implementation` configuration should be used to declare dependencies which are internal to the component.

Example 4. Adding dependencies
build.gradle.kts

    library {
        dependencies {
            api("io.qt:core:5.1")
            implementation("io.qt:network:5.1")
        }
    }

build.gradle

    library {
        dependencies {
            api "io.qt:core:5.1"
            implementation "io.qt:network:5.1"
        }
    }

Dependencies appearing in the `api` configurations will be transitively exposed to consumers of the library, and as such will appear on the compile include root and link libraries of consumers. Dependencies found in the `implementation` configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumer’s compile include root and link libraries. This comes with several benefits:

- dependencies do not leak into the compile include roots and link libraries of consumers, so they can never accidentally depend on a transitive dependency

- faster compilation thanks to the reduced include roots and link libraries

- fewer recompilations when implementation dependencies change since the consumer would not need to be recompiled

## Conventions

The C++ Library Plugin adds conventions for sources and tasks, shown below.

### Project layout

The C++ Library Plugin assumes the project layout shown below. None of these directories needs to exist or have anything in them. The C++ Library Plugin will compile whatever it finds and ignore anything missing.

`src/main/cpp`

  C++ source with extension of `.cpp`, `.C++` or `.cc`

`src/main/headers`

  Private headers - headers needed to compile the library but are not needed by consumers

`src/main/public`

  Public headers - headers needed to compile the library and required by consumers

You configure the project layout by configuring the `source`, `privateHeaders` and `publicHeaders` respectively on the `library` script block.

### `compileVariantCpp` Task

The C++ Library Plugin adds a CppCompile instance for each variant of the library component to build (e.g. `compileDebugCpp` and `compileReleaseCpp`). Read the introduction to build variants for more information. Some of the most common configuration options are shown below.

compilerArgs | []
debuggable | `true`
includes | `configurations.cppCompileVariant` + `library.publicHeaders` + `library.privateHeaders`
macros | [:]
objectFileDir | `layout.buildDirectory.dir("obj/main/$variant")`
optimized | `false` for debug build type or `true` otherwise
positionIndependentCode | `true` for shared linkage or `false` otherwise
source | `library.cppSource`
systemIncludes | derived from the tool chain
targetPlatform | derived from the `TargetMachine` of the binary
toolChain | automatically selected based on target machine

### `linkVariant` Task

The C++ Library Plugin adds a LinkSharedLibrary instance for each variant of the library containing shared linkage as a dimension - e.g. `linkDebug` and `linkRelease`. Read the introduction to build variants for more information. Some of the most common configuration options are shown below.

debuggable | `true`
libs | `configurations.nativeLinkVariant`
linkedFile | `layout.buildDirectory.dir("lib/main/$variant/libBaseName[.so|dylib]")` (*nix) or `layout.buildDirectory.dir("lib\main\$variant\baseName.dll")` (Windows)
linkerArgs | []
source | `compileVariantCpp.objects`
targetPlatform | derived from the `TargetMachine` of the binary
toolChain | automatically selected based on target machine

### `createVariant` Task

The C++ Library Plugin adds a CreateStaticLibrary instance for each variant of the library containing static linkage as a dimension - e.g. `createDebug` and `createRelease`. Read the introduction to build variants for more information. Some of the most common configuration options are shown below.

outputFile | `layout.buildDirectory.dir("lib/main/variant/libBaseName.a")` (*nix) or `layout.buildDirectory.dir("lib\main\variant\baseName.lib")` (Windows)
source | `compileVariantCpp.objects`
staticLibArgs | []
targetPlatform | derived from the `TargetMachine` of the binary
toolChain | automatically selected based on target machine