This GitHub repository provides an out-of-the-box GitHub Action and Azure Pipeline for building C++ projects. It is designed to lower the barrier to entry for developers, allowing them to easily build, unit test, and package C++ projects for multiple OS combinations using a single C++ source code.
- Ease of use: Set up with minimal configuration required.
- Multiple OS Support: Build your C++ projects for different combinations of operating systems.
- C++ Package Manager Support: Conan package manager is supported out of the box for managing C++ dependencies.
- Automated testing and packaging: Includes support for unit testing and packaging your projects.
- Debug files available: PDB and unstripped files are kept alongside build artifacts.
- Caching support: Conan packages are automatically cached in GitHub actions.
- Multiple CI Platforms: Use GitHub Actions or Azure Pipelines. Also works on-premises or with self-hosted runners/agents.
- A GitHub account
- Basic C++ and CMake skills
- Familiarity with GitHub actions
To get started, fork this repository into your own GitHub account. This will be the home for your C++ CMake project.
The default configuration is stored in pipeline/createMatrix/mergekeys.yml
.
This file stores the Docker images used and various other settings.
Linux builds rely on Docker images.
These docker images must have the following tools installed:
- compilers
- ninja
- conan
Place your C++ source code anywhere in the repository, along with a CMakeLists.txt
file.
This is where you'll define your project and its dependencies.
Create a build-config.yml
file in your repository along with the CMakeLists.txt
file.
This file specifies the build configurations for different operating systems.
Here's an example based on the demo provided in the demo
directory:
demo:
configuration:
win_msvc2022vc142_relwithdebinfo:
<<: *_win_msvc2022vc142_relwithdebinfo
win_msvc2022vc143_relwithdebinfo:
<<: *_win_msvc2022vc143_relwithdebinfo
debian_bookworm_relwithdebinfo:
<<: *_debian_bookworm_relwithdebinfo
debian_bullseye_relwithdebinfo:
<<: *_debian_bullseye_relwithdebinfo
For C++ package management, create a conanfile.txt
or conanfile.py
file in addition to your CMakeLists.txt
file.
To use unit testing and/or packaging, include the necessary CMake files for packaging and testing as follows:
project(demo
VERSION 0.1.0
)
# make sure to place the include commands after the project
# command specifying the project name and version
include(../cmake/packaging.cmake)
include(../cmake/testing.cmake)
These includes will enable the GitHub actions pipeline to perform automated testing and packaging of your project.
Testing also requires the googletest framework, just merge the following line to your conanfile.py
:
def requirements(self):
self.requires("gtest/1.14.0")
A complete example of a conanfile.py
can be found here.
Automatically selects the packaging format based on the target OS.
- Windows: Packages are generated as ZIP files.
- Debian-based Linux: Packages are generated as DEB files.
- Red Hat-based Linux: Packages are generated as RPM files.
Besides the mentioned Key Features CPack standard settings are used.
It is recommended to set CPACK_PACKAGE_CONTACT
, otherwise it is automatically set to undefined
.
For Linux it is recommended to set the CPACK_PACKAGING_INSTALL_PREFIX
to whatever is desired. For example:
set(CPACK_PACKAGE_CONTACT "Your name or company")
set(CPACK_PACKAGING_INSTALL_PREFIX "/usr/local/bin/")
For further customization, such as including additional files in the package or changing package metadata, see the CPack documentation.
-
Define test sources: List all the source files associated with your test. For a large test suite, you may want to separate your test sources from your main application sources.
-
Use the
add_gtest_with_xml
Macro: This macro is used to compile the test sources into an executable, link it with Google Test and any necessary project libraries, and set up XML output for the test results. The basic syntax is:add_gtest_with_xml(TARGET_NAME TARGET_LIBRARY TEST_SOURCES)
TARGET_NAME
: A unique name for your test executable.TARGET_LIBRARY
: The library your test executable should be linked against. This is usually your project's main library.TEST_SOURCES
: The source files for your test.
-
Example: For a hypothetical binary named
demo
that tests the functionality indemoLib
, you might write:set(TEST_SOURCES demoTest.cxx) add_gtest_with_xml(demo demoLib ${TEST_SOURCES})
-
Integration with CMakeLists.txt: Add your test configuration to a
CMakeLists.txt
in your project's test directory. If your project structure does not already include a test directory, create one as shown:add_subdirectory(tests)
The build.yml
GitHub action workflow file orchestrates the build process.
It prepares the build environment, installs the necessary dependencies, and executes the build according to the configurations specified in build-config.yml
.
Its use in Azure DevOps is described here.
This process is triggered by push or pull request events to the main branch, or can be triggered manually.
When the build is run, certain directories are automatically set:
- build directory: is set set to
build/make
- install dir: is set to
build/install
via theCMAKE_INSTALL_PREFIX
cache variable - packaging dir: is set to
build/deploy
via theCPACK_OUTPUT_FILE_PREFIX
cache variable
Note: The automation looks in these paths for the build artifacts, such as test results or generated binaries. If you make changes, make sure these directories are still set correctly by the automation.
If you are using private container images, uncomment the following lines in build.yml
and provide the referenced secrets.
# credentials:
# username: ${{ secrets.DOCKERHUB_USER}}
# password: ${{ secrets.DOCKERHUB_PASSWORD}}
For detailed instructions on setting up your local build environment, including configuring Conan and CMake for different build types, see the Build Environment Setup Guide. This guide provides step-by-step instructions to help you get started quickly and efficiently.
If you have any questions or need support, please consider opening an issue in the repository. Contributions to improve the build process or add new features are welcome.