Grog: the mono-repo build tool for the grug-brained dev

This seems to be essentially an alternate syntax for make-style shell command invocation. It’s completely different from actual monorepo-oriented build tools such as Bazel, which constructs a DAG of files (nodes) and commands (edges), simplified in the UI to a DAG of targets. It has some capacity for target logic reuse, but seems to be limited to macro-expansion instead of Bazel’s user-defined build rules.

No way to represent target platforms, thus no toolchains, thus the cross-compilation example is just hardcoding a sequence of GOOS= GOARCH= go build commands. Also no remote execution, so you’re limited to the resources of a single machine (fine for toy projects, but in a monorepo…?).

The most interesting aspect is its use of Pkl for target configuration – this is the first place I’ve seen Pkl used “in the wild”. I’m not personally a fan of the Ruby/Swift style unqualified imports (it makes per-file analysis much more difficult), but at least it’s better than YAML.

Somewhat baffled by Grog’s decision to not use Pkl for its meta-configuration file, though – why have TOML for grog.toml but YAML/JSON/Pkl for the pseudo-Makefile syntax?

Would it be possible to add a tag for build tools?

This seems like a way to paper over using a command runner instead of a build system. As far as I can see the only thing it does is wrap existing commands in a layer of logic to skip rebuilds if the outputs are up to date with the inputs. In other words if you wrote a bunch of shell scripts instead of using a build system, this glues together the task runners into something resembling a build system.

Meanwhile if you have an actual build system this only wraps it by having to duplicate all the dependency logic from scratch in exchange for … automatically caching target assets outside of the build root?

Seems like a solution looking for a problem. Why not bite the bullet and actually just use a build system in the first place?