Open-Source Testing · friendlyanon

cmake-init

cmake-init is a Python-based project scaffolding tool that generates opinionated CMake 3.14+ projects with modern best practices built in. It automates boilerplate setup for executables, libraries (header-only, static, shared), testing, CI/CD, static analysis, and package manager integration.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/friendlyanon/cmake-init

2.5k

GitHub stars

Forks

CMake

Primary language

GPL-3.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	friendlyanon/cmake-init
Owner	friendlyanon
Primary language	CMake
License	GPL-3.0 — OSI-approved
Stars	2.5k
Forks	95
Open issues	24
Latest release	Unknown
Last updated	2026-04-15
Source	https://github.com/friendlyanon/cmake-init

What cmake-init is

The tool generates CMake projects that are FetchContent-ready, separate developer and consumer targets, include install rules with relocatable packages, and integrate clang-tidy, cppcheck, clang-format, code coverage (gcov/LCOV), and optional Conan/vcpkg support. Requires Python 3.8+, CMake 3.20+, and optional tool binaries for static analysis and documentation.

Quickstart

Get the cmake-init source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/friendlyanon/cmake-init.git2cd cmake-init3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Rapid C/C++ Library Authoring

Generate standards-compliant, package-manager-ready library projects (header-only, static, or shared) with FetchContent support, reducing time to integrate into downstream consumers.

CI/CD Pipeline Bootstrapping

Projects auto-include GitHub Actions workflows with clang-tidy, cppcheck, coverage reporting, and preset-based builds, eliminating manual CI scaffolding.

Teaching/Standardizing CMake Practice

Demonstrates modern CMake conventions (3.14+), target separation, and tooling integration for teams adopting industry best practices at scale.

Implementation considerations

Requires Python 3.8+, CMake 3.20+, git, and optional tool dependencies (clang-tidy 18, cppcheck, LCOV, clang-format 18, codespell). Windows users needing static analysis must install Ninja.
Generated projects use CMake presets for IDE integration (VSCode, CLion); ensure your toolchain supports CMakePresets.json (CMake 3.21+).
Package manager integration (Conan or vcpkg) is optional; choose based on existing dependency management strategy.
Doxygen documentation generation requires version 1.8.x (not 1.9+) due to m.css compatibility; document this constraint in your team's setup guide.
Generated CI assumes GitHub Actions and includes example secrets/deployment configs; adaptation required for GitLab CI, Jenkins, or other platforms.

When to avoid it — and what to weigh

GPL-3.0 License Incompatibility — Generated projects inherit GPL-3.0 terms. Do not use if your organization prohibits strong copyleft licenses or requires proprietary/permissive licensing.
Non-Standard Project Structures — Tool targets common patterns (single executable, library, or header-only project). Complex monorepos, polyglot builds, or bespoke architectures require manual CMake expertise.
Windows-Only or Non-GitHub Workflows — Generated CI workflows are GitHub Actions–specific; clang-tidy/cppcheck on Windows require Ninja generator. Non-GitHub platforms need adaptation.
Minimal Dependency on External Tools — Full feature utilization (static analysis, coverage, formatting) requires installing clang-tidy 18, cppcheck, LCOV, clang-format 18, and optional package managers—significant environment setup.

License & commercial use

GPL-3.0 (GNU General Public License v3.0). This is a strong copyleft license requiring derivative works and distributed copies to also be GPL-3.0. Generated projects inherit this licensing requirement.

Requires careful review. GPL-3.0 permits commercial use but requires source disclosure and propagates the copyleft obligation to all derivative works. Distributing closed-source software built with or derived from cmake-init–generated projects is likely non-compliant. Consult legal counsel before using in proprietary products.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Generated projects include static analysis (clang-tidy, cppcheck) and dynamic analysis (sanitizers, coverage) tooling integration to aid vulnerability detection during development. No documented supply-chain security, dependency pinning, or build reproducibility guarantees. Verify tool versions (clang-tidy 18, clang-format 18) in CI and locally match to avoid silent discrepancies.

Alternatives to consider

Boost.Cpp.Build

B2/Bjam build system alternative; less IDE-friendly than CMake; steeper learning curve for teams standardizing on CMake.

Manual CMake Boilerplate (Modern CMake by Dominik Berner, CppCon talks)

No tooling overhead; full control; requires deep CMake expertise; no automation for CI/code quality setup.

Cookiecutter (generic Python template tool) + custom CMake template

More flexible; requires authoring your own CMake template; lacks cmake-init's opinionated best practices and tool integrations.

Software development agency

Build on cmake-init with DEV.co software developers

Generate standards-compliant, production-ready CMake projects in seconds. Includes pre-configured CI, static analysis, testing, and package manager integration—ideal for libraries and executables. Note: GPL-3.0 licensed; review commercial implications before use.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

CMock tox mull

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing AI Development Custom Software Development DevOps Talk to DEV.co

cmake-init FAQ

Can I use cmake-init for proprietary/closed-source software?

Not directly without legal risk. GPL-3.0 requires source disclosure. Consider consulting counsel or requesting an alternate license from the maintainer (unlikely). Use Manual CMake or a permissive-licensed alternative instead.

Does cmake-init support Meson, Bazel, or other build systems?

No. Tool generates CMake-only projects. If your org uses multiple build systems, you'll need parallel boilerplates or manual adaptation.

What if I can't install all optional tools (clang-tidy 18, LCOV, Doxygen)?

Core CMake generation works without them. Generated CI will attempt to run missing tools and fail; remove or skip those jobs in GitHub Actions workflow. Local development remains functional without optional tools, but CI checks will break.

Are generated projects automatically compatible with vcpkg and Conan?

cmake-init can auto-generate integration hooks for Conan and vcpkg using the `-p` flag. However, you must set up vcpkg/Conan separately; cmake-init does not install or configure them.

Software development & web development with DEV.co

Adopting cmake-init is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source testing software in production.

Accelerate C/C++ Project Setup with cmake-init

Talk to DEV.co Schedule a Consultation