我有一个小型 ANSI C 应用程序,它可以在不同的测试编译器和平台下干净地编译。它不使用任何预处理器开关或外部依赖项,makefile 类似于:
myapp: *.c
gcc *.c -Wall -o myapp
如果我想以尽可能可移植的源形式分发这个项目,我应该使用 automake/autoconf 包装它吗?这实际上会增加便携性,还是像它一样便携?
我唯一能想到的是它会自动选择系统编译器,但它也会增加很多复杂性。这值得么?
我有一个小型 ANSI C 应用程序,它可以在不同的测试编译器和平台下干净地编译。它不使用任何预处理器开关或外部依赖项,makefile 类似于:
myapp: *.c
gcc *.c -Wall -o myapp
如果我想以尽可能可移植的源形式分发这个项目,我应该使用 automake/autoconf 包装它吗?这实际上会增加便携性,还是像它一样便携?
我唯一能想到的是它会自动选择系统编译器,但它也会增加很多复杂性。这值得么?
我怀疑这是否值得。每个具有工作 C 编译器的平台都应该支持没有任何特定于操作系统调用的 ANSI C,并且在其中添加 automake/autoconf 会使维护可能不如目前那么愉快。
但是,您可以使用$(CC)
makefile 中的变量来自动使用系统的编译器:
myapp: *.c
$(CC) *.c $(CFLAGS) -o myapp
您不需要指定编译规则,因此不需要 in和$(CC)
,因为有一个隐式规则可以从 C 源代码生成可执行文件。$(CFLAGS)
$(LDFLAGS)
make
保持Makefile
简单:
all: myapp
myapp: *.c
clean:
rm -f myapp
.PHONY: all clean
顺便说一句,最好指定源文件列表,因为不能保证您的源将是该目录中唯一的 C 文件
尽管您可能觉得在功能方面收获甚微,但出于以下原因,您可能仍希望考虑它: