Show HN: I built a Cargo-like build tool for C/C++

Original Article ↗ Hacker News Discussion ↗

A new “Cargo‑like” tool for managing C/C++ builds and dependencies, built as a wrapper around CMake, is drawing both interest and skepticism. Commenters welcome attempts to simplify C/C++ project setup but argue that layering another generator on top of CMake risks adding complexity without solving hard problems like cross‑compilation, ABI compatibility, offline builds, and IDE integration—domains where tools such as CMake, Conan, vcpkg, Meson, or xmake already compete. Security concerns over curl‑piped installers and fears of further ecosystem fragmentation lead some to call for strengthening existing de facto standards rather than introducing yet another partial solution.

Overall reaction

  • Mixed response: some welcome a cargo-like tool to simplify C/C++ project setup; others see “yet another CMake wrapper” as adding complexity instead of solving root problems.
  • Several commenters stress the project is very early; they appreciate the ambition but doubt one person can handle the full real‑world complexity.

CMake vs. “meta-meta” build systems

  • Many argue that layering on top of CMake (a build-system generator) just creates a “build-system generator generator” instead of fixing CMake’s core issues.
  • Others defend CMake as the de facto standard with huge accumulated knowledge about platforms, compilers, IDEs, and edge cases; replacing it is seen as very hard.
  • Some prefer plain Make for simplicity on small projects; others reply that cross-platform, IDE integration, and complex dependency graphs quickly exceed Make’s comfort zone.

Dependency and package management

  • Comparisons drawn to Conan, vcpkg, and xmake; some say these already are the “cargo for C/C++” in practice, especially Conan2 with profiles, ABI modeling, binaries, lockfiles, and cross-compilation.
  • Concern that a new tool without full cross-compilation, offline builds, system-dependency handling, and ABI/version conflict resolution can’t realistically become a universal standard.
  • Requests for integration with existing mechanisms (pkg-config, CPS) and system package managers, plus ability to specify dependencies manually for offline/sandboxed builds.

Cross-platform, toolchains, and performance flags

  • Several emphasize cross-compilation as a first-class requirement (embedded, consoles, different OSes); any tool that treats it as an afterthought is seen as non-viable.
  • Advice to avoid aggressive defaults like -O3 -march=native; considered a red flag for portability and distribution.

Security and installation

  • Strong criticism of curl | sh installer patterns as a supply-chain risk, even if inspired by rustup.
  • Some argue it’s convenient; others insist it’s strictly worse than shipping a static binary.

AI, configuration languages, and ecosystem

  • One camp argues modern AI can generate ad-hoc build scripts on demand, reducing the value of learning or inventing new build DSLs.
  • Others prefer declarative config (e.g., TOML) but warn that non–Turing-complete formats struggle with complex conditional logic.
  • Additional skepticism raised about apparent AI-generated code and descriptions, and about name collisions (e.g., KDE’s existing “Craft” tool).