【发布时间】:2012-10-23 22:07:36
【问题描述】:
我负责构建多个 RPM。对于我需要制作的每个 RPM 包,我都有原始的 SPEC 文件,并且我有 BASH 脚本来设置必要的环境并构建 RPM。
我想使用实际的构建工具(例如 make)来构建这些 RPM。通过这样做,我希望消除对自定义的、混淆的 BASH 脚本的需求,而使用清晰、可维护的配置文件(类似于 make 的 Makefile)。然而,使用POSIX make 并保持 make 文件集是最新的可能与维护我目前用于构建 RPM 包的 BASH 脚本一样多。像 cmake 和 automake 这样的程序包含 make 命令的功能是有原因的 - 这些工具更具表现力,允许更小、更清晰的配置文件。
但是,使用autoconf/automake 似乎也是一个糟糕的选择,因为它们似乎是专门为 C 和 C++ 开发而构建的。也有人建议我使用scons,但尽管这似乎是最佳选择(因为它的配置文件是实际的 Python 脚本),但它也适用于特定语言。
将我的 SPEC 文件用作“源代码”,将环境用作“依赖项”(例如设置制作 RPM 所需的 rpmbuild 目录树结构),是否有一个好的构建工具可以用来替换我的 BASH 脚本更清洁、更可维护的 RPM 构建解决方案?
编辑:当我说“构建工具”时,我似乎不清楚我需要什么。我已经使用 rpmbuild 作为“编译器”,我使用 SPEC 文件(以及二进制文件的相关源代码)作为“源代码”来“编译”RPM。我正在寻求一种可以协调该过程的工具。
【问题讨论】:
-
rpmbuildlinux.die.net/man/8/rpmbuild 怎么了? -
您提到的所有工具都负责创建“最终”分发文件。这是按照源作者的意图完成的。您正在寻找的生活要高一级。一步之后。
-
正如下面评论中所述,没有 rpmbuild 就无法制作 RPM。我已经用过那个工具了。但是,我有很多 RPM 需要构建,因此我将 rpmbuild 视为构建工具(如 make),而不是将其视为“编译器”,将 SPEC 文件视为“源代码”。这些 RPM 共同组成一个套件,这是构建工具将生成的产品。