Other than the complete lack of writing CMake, Makefiles, autoconf, or any number of other end-user-configuration complicated systems as such, and other than the trivial statically-linked cross-compilation support, sure, I guess it's "just" a wrapper around clang, if you squint.

Out of curiosity, what DO you write instead of Makefiles in this case?

I’m genuinely curious if it’s actually easier, but I’m assuming you’re just using a different tool, maybe without as much historical baggage (and incompatible implementations)…

If you aren’t supporting more than one compiler, almost all of those tools vanish. You can just use clang.

If you aren't supporting more than one compiler, aren't needing to compile anything in parallel, aren't needing to find and link shared libraries on the system, aren't needing to deal with any number of real complexities that happen when building C software, then sure, build.sh calling clang a few times manually is absolutely reasonable. (And again: cross-compilation is a real concern: shipping for amd64 only is not enough in 2023). And to be clear - there are plenty of small-scale projects that fit this description! But to simply hand-wave away `zig build` or other modernized build systems and say "just use clang directly" seems a bit dishonest or incomplete to me.

Note that I am not advocating for just having a few shell scripts that invoke clang. The context is someone saying to use `zig build`, and linking a blog post where all they do is compile redis from scratch, including all dependencies from source except for libc. In that context, `zig build` is just a wrapper around clang. Nowhere in their comment or linked blog post is the issue of these real complexities you allude to addressed at all.

Now I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C projects instead of a cross-platform C compiler, but people can do whatever they want.

Or more than one operating system, or more than one stdlib, etc., etc.

to be fair - my goto move on a smallish project when autoconf barfs is 'cc *.c -o foo'. it works pretty damn often, sometimes you need to throw in some -I action

> or any number of other end-user-configuration complicated systems as such

If you think that cmake is complicated, when in reality all it does is set targets using a declarative stye, then programming might not be for you.

Personal attacks are pretty unnecessary here, thanks. This kind of comment is what gives (some) C developers the reputation they have in some circles, I guess.

> when in reality all it does is set targets using a declarative stye

That's like the hello world of cmake builds

Bigger cmake builds are doing dependency resolution, configuration tests, and configuration for development or release builds/installs.

Go poke at the cmake logs and result artifacts in Debug/Release build types and see if it's "just declaring targets."

> Bigger cmake builds are doing dependency resolution,

find_package(foo)

#...

target_link_libraries(myapp foo::Static)

> configuration tests,

I don't know what you mean by configuration tests. I don't think I ever added any test resembling that description other than sanity checks in cmake find modules and sanity checks on projects just for convenience.

> and configuration for development or release builds

Those are not handled by cmake other than setting a flag that's used in the code.

> /installs.

You don't need to do anything other than setting the install target.

https://cmake.org/cmake/help/latest/command/install.html

I think you're either wildly exaggerating or you've been creating your own problems.

Ok. How does find_package work? Hint: you need to understand how cmake module paths are discovered and their precedence, and you'll probably see a cmake folder in a build with the actual logic behind it as a .cmake file for each dependency. Depending on what package manager you're using you may not need this, or if you support many you'll need to own it.

> I don't know what you mean by configuration tests.

When you run cmake -S <my project> -B build folder you'll see a bunch of output. What this output corresponds to may include a number of tests that either succeed or fail to indicate whether the project will build. For example, the aforementioned find_package logic, finding the compiler tool chain (especially if cross compiling), testing for random shit like endianness, etc.

> Those are not handled by cmake other than setting a flag that's used in the code.

    if(STREQ ${CMAKE_BUILD_TYPE} Release)
        ....
    endif()

Is ridiculously common with the "..." filled in by various things like setting optimization flags, paths within the build directory, etc

> You don't need to do anything other than setting the install target.

No but you should probably understand what RPATH is and why it's set in release builds but not installed artifacts or why doing something that seems obvious like checking the checksum of your built object is the same as the installed one might fail.

The point is that cmake does a lot of work and it's not just declaring targets. Builds are hard.

Here's some more info why you might use this instead of plain clang.

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...