commit 8af18e7816919c5a58ab886e2213707cc38db8d1 parent a3f0f04e1d8b6b406da2d96478ce34a33bc3c267 Author: Samdal <samdal@protonmail.com> Date: Sat, 1 Mar 2025 20:31:53 +0100 build-sh blog clarity Diffstat:
| M | _posts/2025-02-28-build-sh.md | | | 2 | +- |
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_posts/2025-02-28-build-sh.md b/_posts/2025-02-28-build-sh.md @@ -43,7 +43,7 @@ ${CC} ${compiler_flags[*]} ${sources[*]} ${linker_flags[*]} -o ${output} If all your exposure is from "real build systems," you might find this baffling. My advice is to form your own opinions—don't accept the gospel of others without a second thought. -Unity builds have numerous benefits and should be the go-to for shipping. Builds of this kind are easy to port and give the compiler more opportunities for optimization. It is also by far the simplest method for using multiple files. +Unity builds have numerous benefits and should be the go-to for shipping. Builds of this kind are easy to port and give the compiler more opportunities for optimization. It is also by far the simplest method. Structuring your program with the knowledge that it will use a unity build lets us do some tricks. Source files aren't compiled separately, and we control their inclusion order. Exploiting this removes messy `#include` statements. You can even disregard header guards if you dare.