4 ms·
"Make" is great for small projects. But as the project grows people start to fill the Makefile with hacks: all those empty files with "stamp" in the name and sc
by bloak 8y ago
"Make" is great for small projects. But as the project grows people start to fill the Makefile with hacks: all those empty files with "stamp" in the name and scripts called "move-if-change" and other tricks that don't quite follow the rules. And recursive "make" invocations (http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf). Eventually the whole thing becomes so incomprehensible and unreliable that the general advice becomes: do a fresh a checkout before running "make", or build out-of-tree and do "rm -r *" first. You almost certainly have to do that if the stuff you're trying to debug is the build infrastructure itself, which, sadly, is something developers spend an awful lot of time doing.
Don't get me started on Makefiles that invoke Docker.
Some practical advice: don't write a rule like "./script < input > output"; instead write "./script < input > output.new && mv output.new output". That way if the script fails it doesn't leave things in a broken state with "output" appearing to be up-to-date. Perhaps a replacement for "make" would incorporate this mechanism?
A replacement for "make" would also have a proper way of handling the situation in which a file is regenerated and found not to have changed, to replace all those half-working "stamps" and "move-if-change" hacks.
Edit: See also: https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html https://www.gnu.org/software/automake/manual/html_node/Multi... Presumably a decent build system would make this fairly normal situation somewhat easier to handle.
- JdeBP 8y agoThey already do. * http://jdebp.eu./FGA/introduction-to-redo.html http://jdebp.eu./FGA/introduction-to-redo.html (https://news.ycombinator.com/item?id=18398957 https://news.ycombinator.com/item?id=18398957) * https://news.ycombinator.com/item?id=18480433 https://news.ycombinator.com/item?id=18480433 * https://news.ycombinator.com/item?id=18473744 https://news.ycombinator.com/item?id=18473744
- de_watcher 8y agoOh, Docker is especially garbage to automate with usual tools. You have to write an entire application via the API to do stuff somewhat reliably.
- ynik 8y ago> That way if the script fails it doesn't leave things in a broken state with "output" appearing to be up-to-date. Perhaps a replacement for "make" would incorporate this mechanism? GNU make has ".DELETE_ON_ERROR" for this. But yes, make is quite horrible if you want reliable incremental builds. For example, $OLD_VERSION of your software generates a file $output/plugins/stuff.so, and $NEW_VERSION no longer does so, the file will stick around and the new version of the software will load an outdated plugin. This type of stuff causes weird issues that disappear on the next fresh checkout (especially during development, where the plugin ABI may be unstable). If a rule disappears, so should its output file(s) on the next build. Why are there so many build systems that don't even attempt to handle this stuff? Surely we aren't the only project that uses glob patterns like plugins/*.so? You can't fix these fundamental design problems by using meta-build-tools that end up generating makefiles...