2

我有一个小型 ANSI C 应用程序,它可以在不同的测试编译器和平台下干净地编译。它不使用任何预处理器开关或外部依赖项,makefile 类似于:

myapp: *.c
    gcc *.c -Wall -o myapp

如果我想以尽可能可移植的源形式分发这个项目,我应该使用 automake/autoconf 包装它吗?这实际上会增加便携性,还是像它一样便携?

我唯一能想到的是它会自动选择系统编译器,但它也会增加很多复杂性。这值得么?

4

3 回答 3

4

我怀疑这是否值得。每个具有工作 C 编译器的平台都应该支持没有任何特定于操作系统调用的 ANSI C,并且在其中添加 automake/autoconf 会使维护可能不如目前那么愉快。

但是,您可以使用$(CC)makefile 中的变量来自动使用系统的编译器:

myapp: *.c
    $(CC) *.c $(CFLAGS) -o myapp
于 2009-10-28T09:06:16.897 回答
4

您不需要指定编译规则,因此不需要 in和$(CC),因为有一个隐式规则可以从 C 源代码生成可执行文件。$(CFLAGS)$(LDFLAGS)make

保持Makefile简单:

all: myapp

myapp: *.c

clean:
    rm -f myapp

.PHONY: all clean

顺便说一句,最好指定源文件列表,因为不能保证您的源将是该目录中唯一的 C 文件

于 2009-10-28T09:29:52.903 回答
0

尽管您可能觉得在功能方面收获甚微,但出于以下原因,您可能仍希望考虑它:

  • 使用 autoconf 是分发 C 代码的一种非常常见的方式。因此,大多数人应该对使用它进行构建和安装感到满意,这使用户更容易。
  • 一旦您努力让 autoconf 与您的项目一起工作,如果您确实想要使用它的一些附加功能,它将大大简化它。
于 2009-10-28T09:18:03.333 回答