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…
Redo: A recursive, general-purpose build system
11–20 of 95 posts
Re: Redo: A recursive, general-purpose build system
#12Earlier 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...
Re: Redo: A recursive, general-purpose build system
#13Re: Redo: A recursive, general-purpose build system
#14Earlier 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.
Re: Redo: A recursive, general-purpose build system
#15As 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…
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
#16As 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…
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
#171. 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
#18As 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…
Re: Redo: A recursive, general-purpose build system
#19As 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…
Re: Redo: A recursive, general-purpose build system
#20As 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…
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.