Live data from Hacker News

Redo: A recursive, general-purpose build system

redo.readthedocs.io

11–20 of 95 posts

Re: Redo: A recursive, general-purpose build system

#11

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 executi…

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.

Re: Redo: A recursive, general-purpose build system

#12
post #7

Earlier quoted context omitted.

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).

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...

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.

Re: Redo: A recursive, general-purpose build system

#14
post #7

Earlier quoted context omitted.

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...

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.

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.

Re: Redo: A recursive, general-purpose build system

#15

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 executi…

I second Bazel. People keep on mentioning how steep the learning curve is, but the conceptual model is really simple, elegant, and intuitive.

What is steep is the technical know-hows:

1. When things don't work as expected. For example, while it worked flawlessly with languages that it natively support such as Java, that wasn't the case for other languages such as Javascript or Python.

2. When you have to do something advanced such as building custom Bazel rule. You'll need to understand Bazel internals and unfortunately the documentation isn't very intuitive and also somewhat sparse.

Re: Redo: A recursive, general-purpose build system

#16

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 executi…

> All the alternative build systems wisely choose to tackle only some of these features.

But why should all of these features be tackled by a single piece of software? Especially seeing how Make, in itself, has proven wildly insufficient already... what, 30 years ago, when GNU autotools came onto the scene?

More specifically, why do you find combinations such as meson + ninja, or CMake + ninja, or even CMake + make as superior to just-Make?

Re: Redo: A recursive, general-purpose build system

#17
Some obvious questions:

1. How does redo compare with lower-level build tools such as ninja?

2. Why is it important/worthwhile to create a simplified/elegant version of Make, when for a few decades already, it is customary to write something higher-level that generates Makefiles (or builds in ways other than through Make, like scons or again via ninja)?

3. Is there a redo generator for CMake, and does it have advantages over Makefile generation?

Re: Redo: A recursive, general-purpose build system

#18

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 executi…

Not just a functional language -- I found that my ability to write maintainable (and performance) Makefiles drastically improved when I began to think of Make as a Prolog/Datalog variant with particularly heinous syntax and very limited constraint resolution.

Re: Redo: A recursive, general-purpose build system

#19
post #15

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 executi…

I second Bazel. People keep on mentioning how steep the learning curve is, but the conceptual model is really simple, elegant, and intuitive. What is steep is the technical know-hows: 1. When things don't work as expected. For example, while it worked flawlessly with languages that it natively support such as Java, that wasn't the case for other languages such as Javascript or Python. 2. When you have to do something…

Bazel is awful unless you're Google and have a team of devs supporting Bazel.

Re: Redo: A recursive, general-purpose build system

#20

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 executi…

I don't like using tabs in Makefile syntax. Tabs are in many cases (especially on print) indistinguishable from spaces.

Also, any "make" program for C should automatically detect dependencies between files because this information is present in the code and it doesn't make sense to duplicate it.

Post reply on HN