配置文件位置和二进制文件并构建系统，如 autoconf答案

【问题标题】：Config file location and binaries and build systems like autoconf配置文件位置和二进制文件并构建系统，如 autoconf
【发布时间】：2014-11-10 22:11:05
【问题描述】：

大多数构建系统，如autoconf/automake，允许用户指定目标目录来安装运行程序所需的各种文件。通常这包括二进制文件、配置文件、辅助脚本等。

同时，许多可执行文件通常需要从配置文件中读取，以允许用户修改运行时设置。

最终，程序（比如说，编译后的 C 或 C++ 程序）需要知道去哪里才能读取配置文件。很多时候我会将路径硬编码为/etc/MYPROGAM/myprog.conf 之类的东西，这当然不是一个好主意。

但在 autoconf 世界中，用户可能会指定安装前缀，这意味着 C/C++ 代码需要以某种方式意识到这一点。

一种解决方案是指定一个带有 .in 前缀的 C 头文件，它仅用于定义配置文件的位置，例如：

const char* config_file_path = "@CONFIG_FILE_PATH@"; // `CONFIG_FILE_PATH` is defined in `configure.ac`.

这个文件将被命名为constants.h.in，它必须由configure.ac文件处理以输出一个实际的头文件，然后可以包含在任何.c或.cpp文件中需要它.

这是处理这类事情的通常方式吗？好像有点麻烦，不知道有没有更好的解决办法。

【问题讨论】：

这对我来说当然是一种合理的处理方式。虽然如果用户运行 make install prefix=/some/other/path 而不是 ./configure --prefix=/some/other/path 将无济于事，但我不确定这是否“应该”在一般情况下工作。

标签： c++ c makefile autoconf

【解决方案1】：

对于如何处理这个问题，基本上有两种选择。

一种选择是执行您提到的操作 - 将相关路径编译到生成的可执行文件或库中。这里值得注意的是，如果文件安装在前缀的不同子部分中，那么每个这样的东西都需要自己的编译时路径。这是因为用户可能会分别指定--prefix 与--bindir，与--libexecdir 等分开指定。这里的另一个问题是，如果有多个安装的程序相互引用，那么这个过程可能应该考虑到程序名称转换（参见--program-transform-name 和朋友的文档）。

当然，如果您想要全面的概括性，那就是全部了。

另一种方法是让程序在运行时可重定位。许多 GNU 项目（至少 gdb 和 gcc）都采用这种方法。这里的想法是让程序在运行时尝试在文件系统中定位其数据。在我最熟悉的项目中，这是通过 libiberty 函数make_relative_prefix 完成的；但我相信还有其他方法。

这种方法经常被吹捧为更好，因为它允许程序的安装树被tared up 并交付给用户；但在发行版的日子里，在我看来，它不像以前那么有用了。我认为这种方法的主要缺点是，即使不是不可能，也很难同时支持重定位和全套配置安装时选项。

我认为，您选择哪一个取决于您的用户想要什么。

另外，回答上面的评论：我认为更改配置时间和构建时间之间的前缀并不是真正支持的，尽管它可能适用于某些包。相反，处理此问题的常用方法是要求在配置时进行选择，或者支持更有限的 DESTDIR 功能。

【讨论】：