commit a3f0f04e1d8b6b406da2d96478ce34a33bc3c267
parent 486e42a92356606d5be10c7af556f9380d93b8e2
Author: Samdal <samdal@protonmail.com>
Date: Sat, 1 Mar 2025 20:28:32 +0100
fix inline code padding, update build.sh blog
Diffstat:
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/_posts/2025-02-28-build-sh.md b/_posts/2025-02-28-build-sh.md
@@ -18,9 +18,7 @@ And optionally:
## The unity build
-Unity builds are not incremental. They work by `#include`-ing all source code into one file, and then compiling a single translation unit.
-
-Unity builds should be the go-to method for shipping a program. It's easy to port the script, and Unity builds give the compiler more opportunities for optimization.
+Unity builds are not incremental. They work by `#include`-ing all source code into one file and compiling it as a single translation unit.
```c
// unity.c
@@ -30,7 +28,6 @@ Unity builds should be the go-to method for shipping a program. It's easy to por
#include "fs.c"
#include "main.c"
```
-
```sh
#!/bin/bash
@@ -43,11 +40,23 @@ linker_flags=(-fuse-ld=mold)
${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.
+
+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.
+
+The benefit is less clutter in your header and source files. Less includes also means less work for the compiler. In some cases, unity builds have shorter clean-build times.
+Doing this will make LSPs or editor linting less effective, but that's not a big deal. The only real problem is symbol collisions inside the single translation unit, which may or may not be trivial.
## The incremental build
-You may want to do an incremental build if your project is "too complex." Incremental builds are rarely necessary.
+Although unity builds provide many benefits, you may want to do an incremental build if your project is "too complex."
+
+Before we start, if your project is too complex, your first attempt should be to fix the core problem. Incremental builds are not an excuse to spread source code across hundreds of files and to create cyclic dependencies.
+With that out of the way, here is a `build.sh` for multiple source files built in parallel.
```sh
#!/bin/bash
set -e
@@ -122,7 +131,7 @@ fi
mkdir -p $(dirname "${output}")
-### compile and run metaprogram ###
+### Compile and run metaprogram ###
if [ ! -f "./bin/codegen" ] || [ "./codegen/codegen.c" -nt "./bin/codegen" ]; then
${CC} -g ./codegen/codegen.c -fuse-ld=mold -o ./bin/codegen
diff --git a/_sass/_main.scss b/_sass/_main.scss
@@ -166,6 +166,7 @@ code {
padding: 0px;
font-family: "Iosevka";
font-size: 80%;
+ padding: 0.1rem;
}
pre {
@@ -179,6 +180,7 @@ pre code {
border: none;
background: transparent;
font-size: inherit;
+ padding: 0;
}
diff --git a/_todo.md b/_todo.md
@@ -1,5 +1,8 @@
# TODO
+## MISC:
+- improve SEO and descriptions
+
## Blog ideas:
### electronics
