我应该使用 automake/autoconf 来分发小型 ansi C 应用程序吗？答案

【问题标题】：Should I use automake/autoconf for distribution of a small ansi C app?我应该使用 automake/autoconf 来分发小型 ansi C 应用程序吗？
【发布时间】：2009-10-28 09:04:53
【问题描述】：

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

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

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

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

【问题讨论】：

'*.c' 表示法是 GNU make 扩展 - 在没有 GNU make 的平台上不一定可用。最好明确列出目标文件。

标签： c portability autoconf automake

【解决方案1】：

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

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

myapp: *.c
    $(CC) *.c $(CFLAGS) -o myapp

【讨论】：

我会使用 $(CC) 与 $(CFLAGS) 和 $(CPPFLAGS) 和 $(LDFLAGS) - 并省略 -Wall 因为它看起来特定于 gcc。
同意 - 不要使用 autoconf。注意 ndim 的评论。

【解决方案2】：

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

保持Makefile 简单：

all: myapp

myapp: *.c

clean:
    rm -f myapp

.PHONY: all clean

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

【讨论】：

【解决方案3】：

尽管您可能觉得在功能方面收获甚微，但您可能仍希望考虑以下原因：

使用 autoconf 是分发 C 代码的一种非常常用方法。因此，大多数人应该对使用它进行构建和安装感到满意，这对用户来说更容易。
一旦您努力让 autoconf 与您的项目一起工作，如果您确实想要使用它的一些附加功能，它将大大简化。李>

【讨论】：

另一方面，如果 'INSTALL' 文件（或者，更可能是 README 文件）说：要编译，运行“make” - 人们会知道该怎么做。
你说的很对，最后还是作者的选择。但是，我最近有理由编写一个脚本来自动化大量软件包的无人值守安装。所有使用 autoconf 的都需要相同的处理，并且处理起来相对简单。使用非标准东西的包裹需要个人的关注和努力，而且真的很麻烦。
免费获得可预测的“make install”和“make uninstall”目标是有好处的。如果人们应该只构建二进制文件并运行它，请保持原样。如果人们会安装二进制文件，那么我会转向自动工具。