[HN Gopher] Redo: A recursive, general-purpose build system
___________________________________________________________________
Redo: A recursive, general-purpose build system
Author : jstearns
Score : 38 points
Date : 2021-12-28 19:31 UTC (3 hours ago)
(HTM) web link (redo.readthedocs.io)
(TXT) w3m dump (redo.readthedocs.io)
| stargrave wrote:
| One of redo's implementations (on Go) has complete documentation
| on the whole redo build system (applicable to most (all?) redo-s)
| usage: http://www.goredo.cypherpunks.ru/Usage-rules.html
| pdimitar wrote:
| Not impressed by shell incantations. What would sell such a tool
| to me is a feature to replace those with new and more intuitive
| syntax. And a terser one, too.
|
| Holding on to how things are done in the shell is not a thing to
| be proud of. I think a lot of us around here stopped counting the
| times we got tripped by globbing, forgetting or misplacing one
| special character in a ${} block, or quoting.
|
| Let those monstrosities die already. Please.
|
| There's this tool -- https://github.com/ejholmes/walk -- that is
| pretty good and I liked it but dropped it for the same reasons:
| it leaves the heavy lifting to you and it depends on your mastery
| in the black arts.
|
| Now obviously I'm not managing huge projects but nowadays
| https://github.com/casey/just serves me just fine for everything
| I need.
| stargrave wrote:
| Nobody forces you to use any kind of shell with redo. Its .do
| files can be anything you want: ELF object files, shell
| scripts, Perl, Python, whatever, just make it executable and
| obey trivial simple rules (stdout and three arguments).
| pdimitar wrote:
| I see. That makes it a little better. At least we can utilize
| higher-level scripting then. Cool.
|
| I'm still not sure about having more than one file that's
| handling building however...
| stargrave wrote:
| And again noone forces you to use multiple files too :-).
| You can literally have just single default.do file for the
| whole project. apenwarr/redo somewhere explicitly noted
| that. Separate .do files are only for convenience and
| ability to automatically depend on target's build rules
| independently from others, that Make just do not do at all.
| pdimitar wrote:
| Well, the fact that this is a bit confusing is not a good
| sign. But maybe I should read the page again and more
| slowly.
| melony wrote:
| > _Let those monstrosities die already. Please._
| https://github.com/thought-machine/please
| pdimitar wrote:
| I got turned off by the docs when I wanted to try this tool
| some months ago, maybe it's worth to revisit. Do you
| recommend it? Do you use it often?
| melony wrote:
| Using it without Bazel experience is not recommended. It is
| very rough around the edges, I often had to refer to Bazel
| docs when using it.
| pdimitar wrote:
| Thanks for the honest take, appreciate it.
| AceJohnny2 wrote:
| As an intensive (and reluctant) user of GNU Make, I keep looking
| for a more modern replacement. Redo is not it.
|
| Make is really a complicated combination of these components:
|
| - a dependency definition language with in-place evaluation and
| half-assed wildcards
|
| - A functional language with extremely limited datatypes
| (effectively just space-separated strings)
|
| - a clunky macro system
|
| - A "distributed" topological execution engine (did you know Make
| can coordinate job slots across recursive executions of Make?
| It's impressive! And shouldn't have to exist!) [1]
|
| All the alternative build systems wisely choose to tackle _only
| some_ of these features. Redo is interesting in that it 's a
| minimal system that leans on existing Unix tools to fill the
| gaps, but I can't say I'm impressed with using Shell as the
| scripting language, though it is arguably more useful than Make's
| home-grown language that too few people know. Edit: actually,
| redo's doesn't enforce Shell, it can be any executable. That's
| more interesting, maybe (flexibility also introduces complexity!)
|
| The most interesting development in this space is the paper
| "Build Systems A La Carte" [2] by Mokhov, Mitchell, & Peyton
| Jones, who did a great job of breaking down build systems to
| their fundamental concepts, and along the way found one
| particular point of the design space that wasn't fulfilled (Table
| 2, p79:16). Unfortunately, I fear it'll be some years before
| something production-ready emerges from that research, (and I'm
| sure I'll be grumpy about some of their implementation details
| anyhow! Build systems do not a happy developer make)
|
| [1] https://www.gnu.org/software/make/manual/html_node/Job-
| Slots...
|
| [2] https://www.microsoft.com/en-
| us/research/uploads/prod/2018/0...
| AceJohnny2 wrote:
| I see GNU Make as sitting on the opposite end of a spectrum
| than Git. Git is fascinating as a sophisticated, featureful
| system emerging from a simple fundamental concept (Merkle tree
| of file hashes), whereas Make is a mish-mash of concepts
| cobbled together to expose a particular set of user features
| (describe and execute a graph of executions _in a factorized
| way_ ).
|
| Git emerged decades after other version control systems were
| first invented, and found a neat abstraction that covered the
| space.
|
| That's why I have such hope for the BSalC paper and what can
| emerge from it.
| qbasic_forever wrote:
| Have you given bazel a serious look? It hits quite a few of the
| points you mention. There's a steep learning curve and you kind
| of have to go all in with it, but once you're there it's quite
| nice.
___________________________________________________________________
(page generated 2021-12-28 23:00 UTC)