回顾一下术语,这是 makefile“规则”的结构:
target: dependencies ...
commands
...
这是我写的makefile:
CC = mpicc
SHAREDLIB = libfmd.so
CFLAGS = -fPIC -Wall -Wno-unused-result -O3 -fopenmp
LFLAGS = -lm -fopenmp -lgsl -lgslcblas
OBJS = $(patsubst %.c,%.o,$(wildcard *.c))
.PHONY: all shared clean
all: shared
shared: $(SHAREDLIB)
$(SHAREDLIB): depend.mk $(OBJS)
$(CC) $(OBJS) -shared -o $@ $(LFLAGS)
depend.mk: *.c *.h
$(CC) -MM *.c > depend.mk
-include depend.mk
clean:
rm -f *.o libfmd.so depend.mk
当文件夹干净后,我输入
make clean
,将显示以下行:
mpicc -MM *.c > depend.mk
rm -f *.o libfmd.so depend.mk
在我看来,
-include depend.mk
除了包含depend.mk
之外,还执行以depend.mk
为目标的规则。我想停止这种行为。
你是对的。 请参阅文档中的如何重新制作 Makefile。
没有办法阻止这种行为:如果有一条规则创建了一个包含的 makefile,那么 make 总是会在它过期时重建它,然后重新调用自身来读取最新版本。
问题是,为什么要避免它? 也许如果您在更高层次上解释了您实际上正在寻找的行为,我们可以提供帮助。 正如您在此处所看到的,可能会在没有创建任何depend.mk文件的情况下创建.o文件,然后编译失败,您可以修改头文件来修复它,但由于当您重新创建时depend.mk文件不存在-run 使源文件未正确重建。
如果您想使用 GCC 准确处理 C/C++ 依赖项,您可以查看自动依赖项生成。
depend.mk: *.c *.h
$(CC) -MM *.c > depend.mk
仅供参考,这是错误的,因为 make 不支持规则字符串中的 shell 通配符。尽管在配方行上可以工作,因为它可以通过外壳本身扩展。
我想停止这种行为
depend.mk 是默认目标的先决条件,因此它无论如何都是一个目标。
此外,对于大型项目来说,预处理到 dependent.mk 的速度很慢,因此切换到手动编写的依赖项,或者使用推荐的方式来生成它们是完全有意义的,正如 @MadScientist 建议的那样。
jiwopene 的想法:仅包含
depend.mk
(如果存在)。它对我来说非常有用。
-include $(wildcard depend.mk)
我们使用
wildcard
函数是因为:来自 John Graham-Cumming 的文章
$(wildcard) 的另一个有用功能是,如果传递给它的文件名不包含模式,则只需“检查该文件是否存在”。如果文件存在,则返回其名称,否则 $(wildcard) 返回空字符串。