我应该使用 automake/autoconf 来分发小型 ansi C 应用程序吗?
Posted
技术标签:
【中文标题】我应该使用 automake/autoconf 来分发小型 ansi C 应用程序吗?【英文标题】:Should I use automake/autoconf for distribution of a small ansi C app? 【发布时间】:2009-10-28 09:04:53 【问题描述】:我有一个小型 ANSI C 应用程序,它可以在不同的测试编译器和平台下干净地编译。它不使用任何预处理器开关或外部依赖项,makefile 类似于:
myapp: *.c
gcc *.c -Wall -o myapp
如果我想以尽可能可移植的源代码形式分发这个项目,我应该使用 automake/autoconf 包装它吗?这实际上会增加便携性,还是像它一样便携?
我唯一能想到的是它会自动选择系统编译器,但也会增加很多复杂性。值得吗?
【问题讨论】:
'*.c' 表示法是 GNU make 扩展 - 在没有 GNU make 的平台上不一定可用。最好明确列出目标文件。 【参考方案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”目标是有好处的。如果人们应该只构建二进制文件并运行它,请保持原样。如果人们会安装二进制文件,那么我会转向自动工具。以上是关于我应该使用 automake/autoconf 来分发小型 ansi C 应用程序吗?的主要内容,如果未能解决你的问题,请参考以下文章
如何正确使用带有子目录的 automake/autoconf?
sh 脚本只显示工具的版本,如果它们安装在系统中。 (clang make automake autoconf cmake)
大型项目使用Automake/Autoconf完成编译配置(标准的编译过程已经变成了简单的三部曲:configure/make/make install,)