Craft, a Cargo-like build and workflow tool for C and C++.

Great, no issue that a bit of LLM slop can't fix. Why even say "I built X"? I'd respect it more if you just said "Claude built X" or something.

KDE already has a meta-build tool for C++ called Craft, which handles dependency management and cross - compilation for CMake-built applications and libraries.

Thank you everyone for the feedback so far! I just wanted to say that I understand this is not a fully cohesive and functional project for every edge case. This is the first day of releasing it to the public and it is only the beginning of the journey. I do not expect to fully solve a problem of this scale on my own, Craft is open source and open to the community for development. I hope that as a community this can grow into a more advanced and widely adopted tool.

Feedback of someone who is used to manage large (>1500) software stack in C / C++ / Fortran / Python / Rust / etc:- (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical.Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reasons.If your build system does not allow to build offline and with manually specified dependencies, you will make life of integrators and package managers miserable and they will avoid your project.(2) Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. People expect code to be portable and shippable.Good default options should be CMake equivalent of "RelWithDebInfo" (meaning: -O2 -g -DNDEBUG ).-O3 can be argued. -march=native is always always a mistake.- (3) Allow your build tool to be built by an other build tool (e.g CMake).Anybody caring about reproducibility will want to start from sources, not from a pre-compiled binary. This also matter for cross compilation.- (4) Please offer a compatibility with pkg-config (https://en.wikipedia.org/wiki/Pkg-config) and if possible CPS (https://cps-org.github.io/cps/overview.html) for both consumption and generation.They are what will allow interoperability between your system and other build systems.- (5) last but not least: Consider seriously the cross-compilation use case.It is common in the world of embedded systems to cross compile. Any build system that does not support cross-compilation will be de facto banned from the embedded domain.

Besides Cargo, you might want to take a look at Python's pyproject.toml standard. https://packaging.python.org/en/latest/guides/writing-pyproj...It's similar, but designed for an existing ecosystem. Cargo is designed for `cargo`, obviously.But `pyproject.toml` is designed for the existing tools to all eventually adopt. (As well as new tools, of course.)

The least painful C/C++ build tool I've used is xmakehttps://github.com/xmake-io/xmakeThe reason why I like it (beyond ease-of-use) is that it can spit out CMakeLists.txt and compile_commands.json for IDE/LSP integration and also supports installing Conan/vcpkg libraries or even Git repos. set_project("myapp") set_languages("c++20") add_requires("conan::fmt/11.0.2", {alias = "fmt"}) add_requires("vcpkg::fmt", {alias = "fmt"}) add_requires("git://github.com/fmtlib/fmt v11.0.2", {alias = "fmt"}) target("myapp") set_kind("binary") add_files("src/*.cpp") add_packages("fmt") Then you use it like # Generate compile_commands.json and CMakeLists.txt $ xmake project -k compile_commands $ xmake project -k cmake # Build + run $ xmake && xmake run myapp

Having to work around a massive C++ software project daily, I wish you luck. We use conan2, and while it can be very challenging to use, I've yet to find something better that can handle incorporating as dependencies ancient projects that still use autoconf or even custom build tooling. It's also very good at detecting and enforcing ABI compatibility, although there are still some gaps. This problem space is incredibly hard and improving it is a prime driver for the creation of many of the languages that came after C/C++

Anyone can make a tool that solves a tiny part of the problem. however the reason no such tool has caught on is because of all the weird special cases you need to handle before it can be useful. Even if you limit your support to desktop: OS/X and Windows that problem will be hard, adding various linux flavors is even more difficult, not to mention BSD. The above is the common/mainstream choices, there Haiku is going to be very different, and I've seen dozens of others over the years, some of them have a following in their niche. Then there are people building for embedded - QNX, vxworks, or even no OS just bare metal - each adding weirdness (and implying cross compiling which makes everything harder because your assumptions are always wrong).I'm sorry I have to be a downer, but the fact is if you can use the word "I" your package manager is obviously not powerful enough for the real world.

Nice. I have been thinking of making something similar. Now hopefully I don't have to!Not sure how big your plans are.My thoughts would be to start as a cmake generator but to eventually replace it. Maybe optionally.And to integrate suppoet for existing package managers like vcpkg.At the same time, I'd want to remain modular enough that's it's not all or nothing. I also don't like locking.But right now package management and build system are decoupled completely. And they are not like that in other ecosystems.For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.

Uses CMAKE, Sorry not for me. Call me old but i prefere good old make or batch. Maybe it's because i can understand those tools. Debugging CMAKE build problems made me hate it. Also i code for embedded CPU and most of the time CMAKE is just overkill and does not play well the compiler/binutils provided. The Platform independency is just not happening in those environments.