gpt4 book ai didi

linux - 令人困惑的 Makefile

转载 作者:塔克拉玛干 更新时间:2023-11-03 01:19:07 24 4
gpt4 key购买 nike

我刚看到这个 makefile,它让我感到困惑:

PROJECT_ROOT = ../..

LIBDIR = $(PROJECT_ROOT)/src/lib

INCDIR = $(PROJECT_ROOT)/include

SRCS = proj_start.c function1.c
LIBS = $(LIBDIR)/libtest.a

OBJS = $(SRCS:.c=.o)
PROJECT = project1
FLAGS = -I$(INCDIR)
CC = gcc $(FLAGS)

.c.o:
$(CC) -c $<

$(PROJECT): $(OBJS)
$(CC) $(OBJS) $(LIBS) -o $@

it: $(PROJECT)

clean:
rm -f $(OBJS) $(PROJECT)

depend: $(SRCS)
$(CC) -M $(SRCS) > dependList
sed -e '1,/^# DO NOT DELETE/!d' Makefile > make.tmp
cat dependList >> make.tmp
mv make.tmp Makefile
rm dependList

# DO NOT DELETE THIS LINE

这些是让我感到困惑的部分:

LIBDIR = $(PROJECT_ROOT)/src/lib

为什么libdir在root/src/lib库中?它不应该是 root/lib 目录(这两个目录都存在于文件层次结构中)吗?

.c.o:
$(CC) -c $<

这到底是做什么用的? “$<”的计算结果为 .c.o?我看到这是一个“后缀规则”,但它们的真正用途是什么?

depend: $(SRCS)
$(CC) -M $(SRCS) > dependList
sed -e '1,/^# DO NOT DELETE/!d' Makefile > make.tmp
cat dependList >> make.tmp
mv make.tmp Makefile
rm dependList

# DO NOT DELETE THIS LINE

为什么我们需要这部分?似乎所有的依赖关系都已经处理好了……?

最佳答案

  1. 是的,将 lib/ 放在 src/ 下看起来是一个糟糕的、违反直觉的设计。

  2. 这个:

    .co: ...

the old way编写隐式规则。现在我们会这样写:

%.o: %.c
...
  1. 这是一种有点 Rube Goldberg(即聪明但过于复杂)的自动依赖处理方式。因此,如果 foo.c 包含行 #include bar.h,则此规则会将行 foo.o: bar.h 附加到生成文件。这实际上很重要。

关于linux - 令人困惑的 Makefile,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46269224/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com