Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: