The C++ Library Plugin is not compatible with the configuration cache.

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.

cpp shared library task graph
Figure 1. C++ Library Plugin default task graph

With static linkage, the diagram changes to the following:

cpp static library task graph
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.

cpp library variant task graph
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:

cpp library configurations
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

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