Programming

20943 readers

25 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

Introduction - redo: a recursive build system (redo.readthedocs.io)

submitted 2 days ago* (last edited 2 days ago) by [email protected] to c/[email protected]

3 comments fedilink hide all child comments

This is like a clean, simple reincarnation of make. And it is fascinating how it works:

Make is essentially a configuration file which textually describes a directed graph (DAG) of dependencies by their path names, together with embedded shell command lines which build each dependency.

This works more or less well, but if some dependency is missing, one has to add "make clean" commands. Or maybe, just to be sure, "make clean" (which would not be necessary if the tool really unambigously defined the build). Or for example if a system library has changed. Or if an optional dependency appears which was not there before.

And it becomes more complex if build steps run in parallel. Therefore, things like "make config" and so on are needed.

D.J. Bernstein examined these ill-defined cases, and came up with an alternative system, which he called "redo".

Redo turns this inside-out: It uses real shell scripts for building stuff, together with special shell commands that define dependencies. And these commands have dependencies as input, they can for example use what the compiler tells them. (The background is that e.g. in a complex C project with lots of #defines, only the C compiler has a precise picture what it needs). The top-level command runs all these build scripts in the right order. (In fact, they could also be written in Lisp, Java or Guile or whatever, as long as they support the common dependency-defining commands.)

The resulting system is surprisingly simple.

One quality for example is that in a source tree, definitions can be build recursively without any special provisions. No top-level Makefile required.

top 3 comments

sorted by: hot top controversial new old

[–] [email protected] 5 points 2 days ago

Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).

By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).

However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.

I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.

[–] [email protected] 3 points 2 days ago

It's an interesting system; it does clutter your workspace with a lot of files, especially if you have a lot of rules. I use it in one project and came away with mixed feelings.

Lots of good, some noise.

[–] [email protected] 2 points 2 days ago

I’m not sure about this… the build systems I work with are either so complex that something like cmake gets used because that way we can support multiple build systems on different platforms without maintaining five different projects, or they are so simple that it frankly doesn’t matter whether it’s make or something else.

And in the former case, i.e. the only case where I even care what tool we use, what I care about the most is speed, so I would want something like ninja instead of make (which cmake conveniently supports). I don’t want to micro-optimize by doing everything myself with redo.