Makefile과 make

make란

make는 "무엇을 만들려면 무엇이 필요하고, 어떤 명령으로 만드는가"를 적은 Makefile을 읽어 빌드를 자동화하는 도구다. 핵심 기능은 증분 빌드(incremental build)다. 타깃 파일과 의존 파일의 최종 수정 시각을 비교해, 의존 파일이 더 새로울 때만 타깃을 다시 만든다. 소스 100개 중 하나만 고쳤다면 그 파일만 다시 컴파일하고 링크한다. 셸 스크립트로 빌드 명령을 나열하면 이 판단을 직접 짜야 한다.

규칙의 모양

target: prerequisites
	recipe

make만 실행하면 첫 번째 타깃(또는 .DEFAULT_GOAL)을 만들고, make foo.o처럼 타깃을 지정할 수도 있다.

변수와 자동 변수

자주 쓰는 함수는 치환 참조 $(SRCS:.c=.o), $(patsubst %.c,%.o,$(SRCS)), $(addprefix src/,$(NAMES)), $(wildcard *.c), $(filter bonus,$(MAKECMDGOALS)) 정도다.

패턴 규칙과 내장 규칙

%.o: %.c는 "어떤 .o든 같은 이름의 .c로 만든다"는 패턴 규칙이다. .c.o:는 같은 뜻의 옛 접미사 규칙이다.

make에는 이미 내장 규칙이 있어서(make -p로 확인, make -r로 끈다) 레시피를 생략해도 컴파일과 링크가 된다. 내장 규칙이 쓰는 변수 이름을 알면 Makefile이 짧아진다.

CFLAGS   = -Wall -Wextra -Werror -MMD -MP
CPPFLAGS = -Iinclude
LDFLAGS  = -Llibft
LDLIBS   = -lft
 
SRCS = main.c read.c write.c
OBJS = $(SRCS:.c=.o)
DEPS = $(SRCS:.c=.d)
 
all: app
 
app: $(OBJS)        # 레시피 생략: 내장 규칙 %: %.o 와 %.o: %.c 가 동작
	$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
 
-include $(DEPS)
 
clean:
	$(RM) $(OBJS) $(DEPS)
 
fclean: clean
	$(RM) app
 
re: fclean
	$(MAKE) all
 
.PHONY: all clean fclean re

라이브러리는 링크 순서가 중요하다. main.o가 libftprintf.a를, 그것이 libft.a를 쓴다면 cc main.o -lftprintf -lft 순서여야 한다. 그래서 라이브러리는 LDLIBS에 두어 오브젝트 뒤에 오게 한다. 자세한 이유는 GCC 컴파일과 링크에 있다.

헤더 의존성 자동화: -MMD -MP

%.o: %.c만 적으면 make는 헤더가 바뀐 것을 모른다. bar.h의 #define이나 구조체 필드 타입을 바꿔도 foo.c가 그대로면 foo.o는 옛 정의로 남고, 링크는 성공하지만 실행이 이상해진다. 매번 make re를 하거나 foo.o: foo.c bar.h를 손으로 적는 대신 컴파일러에게 의존성을 쓰게 한다.

# main.d (자동 생성)
main.o: main.c io.h
io.h:

Makefile에서 -include $(DEPS)로 읽어 들인다. 앞의 -는 첫 빌드처럼 .d가 아직 없을 때 오류를 무시하라는 뜻이다.

.PHONY: 파일이 아닌 타깃

clean, all, re처럼 파일을 만들지 않는 타깃은 .PHONY로 선언한다. 선언하지 않으면 같은 이름의 파일이 디렉터리에 생겼을 때 make가 "이미 최신"이라며 레시피를 건너뛴다. 하위 디렉터리를 도는 타깃을 .PHONY로 만들어 의존성으로 나열하면, 셸 for 루프와 달리 하위 make의 오류에서 멈추고 -j로 병렬 실행도 된다.

SUBDIRS = lib src
.PHONY: all $(SUBDIRS)
all: $(SUBDIRS)
$(SUBDIRS):
	$(MAKE) -C $@

자주 겪는 함정

디버깅 빌드는 Makefile을 고치지 않고 변수로 바꾼다. ifdef DEBUG 블록에서 CFLAGS += -g -fsanitize=address,undefined를 더하면 make DEBUG=1로 켤 수 있다. 다만 옵션이 바뀌어도 오브젝트의 수정 시각은 그대로라 기존 .o가 재사용되므로, 모드를 바꿀 때는 make re를 한다.

큰 프로젝트 구성

• 공통 설정은 Rules.mk 같은 파일로 빼고 include Rules.mk로 읽는다. -include는 없어도 되는 파일에 쓴다.
• 산출물이 여럿이면 make -f Makefile.server처럼 파일을 나누거나, 디렉터리별 Makefile을 $(MAKE) -C로 부른다.
• 깊은 상대 경로(include ../../../rules.mk)가 반복되면 최상위에서 TOPDIR를 넘기거나 $(abspath ...)로 절대 경로를 만든다.
• make -n(실행하지 않고 명령만 출력), -d(판단 과정 출력), -p(내장 규칙·변수 출력), -k(오류가 나도 계속)는 Makefile을 디버깅할 때 쓴다.

make 이후의 빌드 도구

손으로 쓰는 Makefile은 의존성 누락, 플랫폼별 분기, 느린 재귀 make 같은 한계가 있다. 그래서 C/C++ 프로젝트는 빌드 설정을 생성해 주는 도구를 많이 쓴다.

그래도 make는 거의 모든 유닉스 계열 환경에 있고, 작은 C 프로젝트나 임의 작업 자동화에는 여전히 가장 가벼운 선택이다.

정리

• make는 수정 시각 비교로 바뀐 것만 다시 빌드한다. 의존성을 정확히 적는 것이 전부다.
• 헤더 의존성은 -MMD -MP와 -include로 컴파일러에게 맡긴다.
• 파일이 아닌 타깃은 .PHONY, 하위 빌드는 $(MAKE) -C, 재빌드는 re: fclean + $(MAKE) all.
• 내장 규칙의 변수(CFLAGS, CPPFLAGS, LDFLAGS, LDLIBS)를 쓰면 Makefile이 짧고 표준적이 된다.

관련 노트: GCC 컴파일과 링크, C 기초: 컴파일, 자료형, 배열과 문자열, C 디버깅 도구, Java 빌드 도구