Post

Justice Of Toren One Var
@jyn.dev

not one, not two, but *three* new jynposts - jyn.dev/negative-bui... - jyn.dev/i-want-a-bet... - jyn.dev/i-want-a-bet...

jyn.devnegative build dependenciesA build system needs to know not just which files exist, but which shouldn't exist.
Justice Of Toren One Var@jyn.dev

i wrote about the recent cloudflare outage jyn.dev/brownouts-re...

jyn.devbrownouts reveal system boundariesYou have backups for your critical data. Do you have backups for your critical infrastructure?

4 reposts18 likes

Erk
@erk.dev

Would it be ronins job to figure out when the magma description had to be remade? Or would that job end up on the user like with cmake?

Justice Of Toren One Var
@jyn.dev

ronin has the same model as ninja, which means that the responsibility is split between cmake and ronin. cmake would generate the (action :generator) rule, which takes the same :inputs argument as any other action, and ronin reruns it when necessary.

Justice Of Toren One Var
@jyn.dev

the main innovation here compared to Ninja is which :inputs actions can have. in ninja, you can depend on file mtimes anad that's about it. in magma you can do quite advanced filtering which lets you rerun expensive actions less frequently.

Justice Of Toren One Var
@jyn.dev

i believe CMake has some support for autogenerating these rules built-in, but fundamentally Ronin doesn't know what your configure is reading from disk so it doesn't know when it should rerun. this is one place where bazel/buck2/nix do a lot better.