This article focuses on make/Makefile-based build automation and terminal progress bar implementation on Linux, addressing three common pain points: inefficient manual compilation, disorganized dependency management, and unclear terminal output. Core keywords: Makefile, incremental compilation, progress bar.
Technical Specification Snapshot
| Parameter | Description |
|---|---|
| Primary Languages | C / Makefile / Shell |
| Runtime Environment | Linux / Unix-like systems |
| Core Mechanisms | Terminal standard output, file timestamp evaluation |
| Source Platform | Reworked from a CSDN blog post |
| Star Count | Not provided in the original content |
| Core Dependencies | gcc, make, stdio.h, unistd.h |
A Makefile declares targets, dependencies, and actions
make is the executor, and a Makefile is the rule definition file. It is not just a way to “run commands in bulk.” Instead, it describes how a project should be built through a three-part structure: targets, dependencies, and commands.
At its smallest unit, a rule answers two questions: which files a target depends on, and which action to run when those dependencies change. For C projects, this is exactly what replaces manual gcc commands.
app: main.o utils.o
gcc -o $@ $^ # Link all dependency targets into the final executable
main.o: main.c
gcc -c $< # Compile only the current dependency source fileThis rule set shows the core structure of a Makefile: targets, dependency chains, and build actions.
The first target runs by default and serves as make’s entry point
When you run make without explicitly specifying a target, it scans from top to bottom and selects the first target as the entry point. That means the first target should usually be the final artifact, such as all or the executable itself, not clean.
If you place the cleanup rule first, running make may delete build artifacts before doing any useful work. This is one of the most common organizational mistakes beginners make.
make performs automated builds through dependency inference
The inference process in make works like this: starting from the entry target, if the target cannot be generated directly, make continues searching for rules that can build its dependencies, until it reaches files that can be handled directly. It then executes commands in reverse order.
This mechanism gives multi-file projects automatic build resolution. You do not need to manually specify every step in sequence. You only need to ensure that the dependency graph is complete and every action is executable.
mytest: mytest.o process.o
gcc -o $@ $^ # Link all object files
%.o: %.c
gcc -c $< # Use a pattern rule to compile .c files into .o filesThis rule set uses pattern matching to enable batch compilation of structurally similar files.
Use .PHONY only for phony targets, not real files
.PHONY declares a phony target and tells make that the target is not a file on disk, so it should not decide whether to skip execution based on file existence. The most common example is clean.
.PHONY: clean
clean:
rm -f *.o app # Force removal of intermediate files and build artifactsThis prevents failure when a file named clean happens to exist in the current directory.
Incremental compilation depends on modification time, not access time
The efficiency of make comes from incremental compilation. It does not blindly rebuild everything. Instead, it compares the modification time of a target and its dependencies, then rebuilds only the outdated parts.
The key timestamp is Modify Time, which reflects content changes. Access Time only records file access, and Change Time more often reflects metadata changes. Neither is the primary basis for make rebuild decisions.
A changed modification time triggers recompilation
When the modification time of main.c is newer than that of main.o, make treats the target as out of date and recompiles it. This mechanism allows large projects to rebuild only changed files, dramatically reducing build cost.
stat main.c
stat main.o
makeThis command sequence helps diagnose timestamp-related questions such as “Why did this recompile?” or “Why did this not compile?”
Automatic variables and functions determine Makefile maintainability
High-quality Makefiles rarely hardcode file names. Instead, they use automatic variables and functions to build scalable, maintainable rules.
Common automatic variables include: $@ for the target name, $^ for all dependencies, and $< for the first dependency. These variables significantly reduce repetitive code.
CC=gcc
SRC=$(wildcard *.c)
OBJ=$(SRC:.c=.o)
TARGET=app
$(TARGET): $(OBJ)
@$(CC) -o $@ $^ # Link quietly to avoid noisy command echo
%.o: %.c
@$(CC) -c $< # Compile each source file into its object fileThis template already supports automatic source discovery and batch object generation.
@, wildcard, and substitution expressions help standardize projects
@ suppresses command echoing and keeps output cleaner. $(wildcard *.c) automatically collects source files in the current directory. $(SRC:.c=.o) maps the source file list into an object file list.
As the number of project files grows, these expressions are more stable than handwritten dependency lists and are much better suited to continuous integration workflows.
Terminal progress bars rely on carriage returns and buffer flushing
The key to a Linux terminal progress bar is not graphics, but terminal character control. \r moves the cursor back to the beginning of the current line without creating a new line, while \n moves to the next line. To overwrite content on the same line, you must use \r.
At the same time, printf is buffered by default. If you do not flush explicitly, output may remain in the buffer until a newline is printed or the program exits.
#include <stdio.h>
#include <unistd.h>
int main() {
for (int i = 0; i <= 100; ++i) {
printf("\rprogress: %d%%", i); // Return to the beginning of the line and overwrite old content
fflush(stdout); // Flush the standard output buffer immediately
usleep(50000); // Simulate task progress
}
printf("\n");
return 0;
}This program implements the smallest practical dynamic terminal progress bar.
A reusable version should include a fill bar and spinner characters
A truly readable progress bar usually includes a percentage, visual fill, and a rotating spinner. This helps communicate both completion progress and the fact that the program is still running.
#include <stdio.h>
#include <unistd.h>
#define WIDTH 50
int main() {
const char *spin = "|/-\\";
char bar[WIDTH + 1] = {0};
for (int i = 0; i <= 100; ++i) {
int pos = i * WIDTH / 100;
for (int j = 0; j < pos; ++j) {
bar[j] = '='; // Fill the completed portion
}
for (int j = pos; j < WIDTH; ++j) {
bar[j] = ' '; // Pad the remaining portion with spaces
}
bar[WIDTH] = '\0';
printf("\r[%s] %3d%% %c", bar, i, spin[i % 4]); // Refresh the display on the same line
fflush(stdout); // Force output to the terminal
usleep(60000);
}
printf("\n");
return 0;
}This code provides a terminal progress bar implementation much closer to real-world tool output.
The key conclusions from the screenshots can be reduced to three engineering practices
The original screenshots mainly demonstrated rule execution, timestamp changes, pattern matching, and progress bar output behavior.
AI Visual Insight: Most screenshots show the execution flow of make in a Linux terminal, the expansion order of target dependencies, the forced execution behavior of .PHONY, the impact of file timestamp changes on incremental compilation, and the dynamic progress bar effect created by repeatedly overwriting output on a single line with \r + fflush(stdout). Together, they confirm two core ideas: the heart of a Makefile is dependency inference, and the heart of a terminal progress bar is buffer flushing plus cursor return.
The most practical takeaway is to standardize on a unified template
First, use wildcard, substitution expressions, and pattern rules to build a general-purpose template. Second, use .PHONY only for targets such as clean. Third, always call fflush(stdout) for dynamic terminal output.
CC=gcc
TARGET=progress
SRC=$(wildcard *.c)
OBJ=$(SRC:.c=.o)
$(TARGET): $(OBJ)
$(CC) -o $@ $^
%.o: %.c
$(CC) -c $<
.PHONY: clean
clean:
rm -f $(OBJ) $(TARGET)This Makefile is already sufficient to support automated builds for a small Linux C project.
FAQ
Why did I modify a source file, but make did not recompile it?
Usually, either the file’s Modify Time was not actually updated, or the target dependency relationship was not correctly written into the Makefile. Start by checking the dependency chain and the timestamps reported by stat.
Why must clean be used with .PHONY?
Because clean is usually not a real file. If a file with the same name happens to exist in the directory, make may incorrectly treat the target as already up to date, causing the cleanup command not to run.
Why does a progress bar require both \r and fflush(stdout)?
\r moves the cursor back to the beginning of the line so new output can overwrite old content, while fflush(stdout) pushes buffered output to the terminal immediately. Without either one, the dynamic effect becomes unreliable or incorrect.
Core Summary: This article systematically reconstructs the core knowledge behind Makefiles and Linux terminal progress bars, covering dependency relationships, default targets, .PHONY, incremental compilation, timestamp evaluation, automatic variables, pattern rules, and dynamic progress bar implementation based on \r and fflush. It is well suited for C/C++ developers on Linux who want to quickly build a solid foundation in automated builds and terminal interaction.