make
Build automation tool using Makefiles
2 members list make, up 2 in the last 12 weeks, data as of 25 October 2026
Used alongside make
Tools that members list in the same stack as make.
Members who list make in their Stack, by week.
Hacker News mentions: 3 mentions (2007) to 22 mentions (2026)
Imported from Hacker News mentions
Homebrew analytics installs: 6,183 installs (2026) to 5,967 installs (2026)
Imported from Homebrew analytics
Stack Overflow developer survey usage share: 20.75 % of respondents (2023) to 23.42 % of respondents (2025)
Imported from Stack Overflow developer survey
About make
GNU Make is a build automation tool that controls the generation of executables and other files in a program from its source files. Developers use makefiles to specify how to build and install a program, which lets end users build packages without needing to know the build details. Make automatically determines which files need updating based on source file changes and computes the correct order for updates, so only affected files are recompiled after changes. The tool works with any programming language since makefiles contain shell commands that can invoke compilers, linkers, and other tools. Make can also automate installation, deinstallation, documentation generation, and other recurring tasks.
Developed by the GNU Project, Make is implemented in C and runs on BSD, Microsoft Windows, and macOS platforms. It is free software supported by the Free Software Foundation.
Checked 23 October 2026.
@gen_rust_ace
Moves that use make
by Sergei GordeichukAI Tools
Every project gets a single make check that runs lint, format-check and tests for the whole stack at once, and nothing gets committed until it is green. The value is not the automation, it is that there is exactly one thing to remember and no partial-check escape hatch to negotiate with. Per-side targets exist for speed while iterating, but the gate before a commit is always the full one. Written into the project instructions as mandatory, an agent will run it unprompted for the rest of the session.
by Sergei Gordeichuk
Building on plain markdown task files in backlog/in_progress/done, the actual technique is splitting the agent loop into three slash commands that each do exactly one thing. /roll researches the codebase and writes a task file - it implements nothing, which is what keeps planning honest and reviewable. /rock picks up one task and takes it end to end: implement, run the check suite, review the result against the task's own acceptance criteria, refresh the e2e scenarios, commit. /work is a thin loop over a list of task IDs that hands each one to a fresh subagent, so the main context never carries state from the previous task, and parks anything needing a human decision instead of stopping the whole batch. The split matters more than the commands. A single do-everything command quietly merges planning into implementation and you lose the reviewable step in the middle.