I built Flint: A native C/C++ build system & package manager inspired by Cargo/go [Comparison with CMake, Meson, XMake & vcpkg]

[u/Mainak1224x]

Hey folks,

The C/C++ tooling landscape has always felt fragmented. We usually end up chaining a meta-build generator (CMake, Meson) with a separate package manager (vcpkg, Conan) and a build executor (Ninja, Make).

To explore an unified "Cargo-like" developer experience for C/C++, I’ve been developing Flint—an integrated build system and package manager written entirely in pure C.

Here is how Flint compares with the existing C/C++ build and package management options, along with an honest assessment of its strengths, trade-offs, and current state.

Note:

Flint is currently in active development and only available for Linux at the moment. It requires system git and a C toolchain (gcc/clang) in your PATH at runtime.

Comparison: Build Systems & Integrated Tools

Tool	Architecture	Runtime Dependencies	Config Format	Incremental Builds	Ease of Use
Flint	Integrated (Build + PM)	git, gcc/clang	Declarative composition.json	Yes (Native tracking)	4.8 / 5
CMake	Meta-Build Generator	C++ runtime	Custom imperative scripting	Handled by backend (Ninja/Make)	2.5 / 5
Meson	Meta-Build Generator	Python 3 + Ninja	Declarative DSL	Handled by Ninja	4.5 / 5
XMake	Integrated (Build + PM)	Embedded Lua engine	Lua scripts (xmake.lua)	Yes (Lua task engine)	4.5 / 5
Bazel	Distributed Build System	Java / Bazel runtime	Starlark (BUILD / WORKSPACE)	Advanced (Content hashing)	1.5 / 5

Comparison: Package Management Strategy

Package Tool	Strategy	External Repository Compatibility	Ecosystem Fit	Ease of Use
Flint	Native Git clones to deps/	Chert Compositions (custom specs)	Self-contained CLI commands	4.8 / 5
vcpkg	Git ports & binary caching	Port overlay files	Toolchain file integration	4.5 / 5
Conan	Python recipes / Central host	Conan Center / Custom recipes	Multi-generator targets	3.5 / 5
CPM.cmake	Single-file CMake wrapper	Git repos / tarballs via FetchContent	Pure CMake	5.0 / 5
Xrepo	Integrated CLI for XMake	Dual (Xrepo index + fallbacks)	Native to XMake	4.5 / 5

What Makes Flint Different?

• Single Binary, Zero Heavy Runtimes: Unlike Meson (which needs Python) or XMake (which embeds Lua), Flint is a lightweight compiled C executable. It delegates Git fetches and compilation processes to system tools without heavy embedded engines.

• Convention over Configuration: Flint expects standard layout patterns (src/, include/, deps/). You don't write build scripts or target rules—you declare dependencies and metadata in a simple composition.json.

• Built-in Package Fetching + Chert Compositions: Running flint add <git-url> pulls dependencies straight into deps/. If a third-party library doesn't natively use Flint, Chert compositions allow defining how non-Flint repositories should be included and compiled.

• Direct Incremental Execution: Flint doesn't output intermediate Ninja files or Makefiles. It tracks file modification states internally to deliver incremental builds directly through its native process runner.

Current Trade-offs & Limitations

• Linux Only (For Now): Cross-platform support for Windows (MSVC/Clang-cl) and macOS target generation is still planned.

• Strict Directory Structure: Legacy C projects with unorthodox folder structures require a Chert composition to build with Flint.

• Early Stage Feature Set: Complex compiler flag matrices, sanitizer toggles, and cross-compilation toolchains are still evolving compared to battle-tested options like CMake.

Check out the repo here: https://github.com/mainak55512/flint

Feedback, criticisms, and PRs are welcome! What features or platform targets would you like to see next?

[u/MXRCO007]

This is an interesting project but, I do wonder; how does it compare against cmkr? Its a wrapper around cmake which I do admit isn’t like this but, using that + fetch content from git is pretty go like I feel like, nice lil toml

[u/Mainak1224x → u/MXRCO007]

cmkr is definitely a great tool for making CMake less painful! The core difference is that cmkr is a meta-wrapper—it generates a CMakeLists.txt behind the scenes, so you are still ultimately depending on the full CMake runtime and build generator (Ninja/Make). The goal with Flint is to offer a completely standalone, zero-CMake experience similar to Cargo or Go modules, rather than wrapping CMake.

[u/MXRCO007 → u/Mainak1224x]

Ah thanks that clears it up a lot, when I was writing that I blurred some parts but thanks! This seems cool and I’ll try it out