Show HN: I built a Cargo-like build tool for C/C++ (github.com)

- (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.

https://github.com/xmake-io/xmake

The 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")

  # Generate compile_commands.json and CMakeLists.txt
  $ xmake project -k compile_commands
  $ xmake project -k cmake

  # Build + run
  $ xmake && xmake run myapp

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.)

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.

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.

This is now a build system generator generator. This is the wrong solution imho. The right solution is to just build a build system that doesn’t suck. Cmake sucks. Generating suck is the wrong angle imho.

Here's my feeble attempt using Deno as base (it's extremely opinionated though and mostly for personal use in my hobby projects):

https://github.com/floooh/fibs

One interesting chicken-egg-problem I couldn't solve is how to figure out the C/C++ toolchain that's going to be used without running cmake on a 'dummy project file' first. For some toolchain/IDE combos (most notably Xcode and VStudio) cmake's toolchain detection takes a lot of time unfortunately.

CMake is a combination of a warthog of a specification language, and mechanisms for handling a zillion idiosyncracies and corners cases of everything.

I doubt than < 10,000 lines of C code can cover much of that.

I am also doubtful that developers are able to express the exact relations and semantic nuances they want to, as opposed to some default that may make sense for many projects, but not all.

Still - if it helps people get started on simpler or more straightforward projects - that's neat :-)

> You describe your project in a simple craft.toml

I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.

How does craft handle these 'diamond' patterns where 2 dependencies may depend on versions of the same library as transitive dependencies (either for static or dynamic linking or as header-only includes) without custom build scripts like the Conan approach?

What exactly is it you do/need that can't be reasonably solved using the FetchContent module?

https://cmake.org/cmake/help/latest/module/FetchContent.html

  // Open source directory
      dir_t* dir = open_dir(source_dir);

  // Find where dot is
      char* dot = strrchr(file, '.');

What I've been doing to manage dependencies in a way that doesn't depress me much has been Nix flakes, which allows me a pretty straightforward nix build with the correct dependencies built in.

I'm just a bit curious though; a lot of C libraries are system-wide, and usually require the system package manager (e.g. libsdl2-dev) does this have an elegant way to handle those?

C++ build system, at the core, boils down to calling gcc foo.c -o foo.obj / link foo.obj foo.exe (please forgive if I got they syntax wrong).

Sure, you have more .c files, and you pass some flags but that's the core.

I've recently started a new C++ program from scratch.

What build system did I write?

I didn't. I told Claude:

"Write a bun typescript script build.ts that compiles the .cpp files with cl and creates foo.exe. Create release and debug builds, trigger release build with -release cmd-line flag".

And it did it in minutes and it worked. And I can expand it with similar instructions. I can ask for release build with all the sanitize flags and claude will add it.

The particulars don't matter. I could have asked for a makefile, or cmake file or ninja or a script written in python or in ruby or in Go or in rust. I just like using bun for scripting.

The point is that in the past I tried to learn cmake and good lord, it's days spent learning something that I'll spent 1 hr using.

It just doesn't make sense to learn any of those tools given that claude can give me working any build system in minutes.

It makes even less sense to create new build tools. Even if you create the most amazing tool, I would still choose spending a minute asking claude than spending days learning arbitrary syntax of a new tool.

https://cmkr.build/

But how this tool figures out where the header files and build instructions for the libraries are that are included? Any expected layout or industry wide consensus?

PS is there a plan to include hermetic builds, from local sources / git submodules?

Once you appreciate the vastness of the problem, you will see that having a vibrant ecosystem of different competing package managers sucks. This is a problem where ONE standard that can handle every situation is incalculably better than many different solutions which solve only slices of the problem. I don't care how terse craft's toml file is - if it can't cross compile, it's useless to me. So my project can never use your tool, which implies other projects will have the same problem, which implies you're not the one package manager / build system, which means you're part of the problem, not the solution. The Right Thing is to adopt one unilateral standard for all projects. If you're remotely interested in working on package managers, the best way to help the human race is to fix all of the outstanding things about Conan that prevent it from being the One Thing. It's the closest to being the One Thing, and yet there are still many hanging chads:

- its terribly written documentation

- its incomplete support for editable packages

- its only nascent support for "workspaces"

- its lack of NVIDIA recipes

If you really can't stand to work on Conan (I wouldn't blame you), another effort that could help is the common package specification format (CPS). Making that a thing would also be a huge improvement. In fact, if it succeeds, then you'd be free to compete with conan's "frontend" ergonomics without having to compete with the ecosystem.