Devlog: Fixing Flower’s Compiler Process So It Stops Fighting the Host

This wasn’t really about language design at all buttttt it is much more embarrassing, AND more important: Flower’s compiler process itself was too fragile.

The immediate issue showed up on Linux, specifically NixOS (thanks shipwrights <3). The build flow was assuming too much:

• a previously existing bin/Flower could be reused safely
• bash would exist at the expected path
• clang would always be available
• the checked-in compiler binary would be runnable on whatever machine the repo landed on

That worked well enough on my machine until it didn’t. On NixOS — and by extension probably any other machine without the prexisting binaries I had — it broke: make targets were inconsistent, the shell script failed on interpreter assumptions, and the compiler binary itself could be the wrong format for the host.

What changed

The fix was to separate “the compiler source exists” from “the current compiler binary is usable on this machine.”

The build process now starts by compiling a fresh host-native bootstrap compiler from bin/Flower.c, instead of trusting whatever happens to already exist in bin/Flower.

That means the flow is now:

bin/Flower.c -> host-native bootstrap compiler -> new Flower compiler -> self-check

instead of:

maybe existing bin/Flower -> hopefully works -> maybe bootstrap

Ok well that’s kinda a lie; it still relies on hopes and dreams to bootstrap sometimes. BUT it’s MUCH safer! And now everyone gets to experience crippling bootstrap anxiety, instead of being met with a failure before the actual compiler gets to.. well, do its thign!

I also cleaned up the surrounding tooling:

• switched the bootstrap script to portable sh
• restored a clearer build / bootstrap / rebuild / test / clean structure
• made the compiler use CC and CFLAGS from the environment instead of hardcoding clang

What this actually improves

Flower is still not universally cross-platform yet. The compiler driver still has POSIX-shaped assumptions in places, and the emitted C can still depend on host APIs depending on what the program uses. I’m not yet at the point of wanting to make it completely universal, especially given how I’m only one person and with v2.0 coming up soon it’d — in my humblest of opinions — be a waste of time.

I am honestly grateful for people reviewing my code and otherwise viewing it catching onto details I have overlooked. My goal is to not make a ‘just-barely working on my machine’ project; I enjoy sharing development with others, and it hurts knowing people can’t appreciate code, whether it be mine or others’, due to something as simple as hard-coded sh flags.