c++ - 配置文件位置和二进制文件并构建系统，如 autoconf

Question

大多数构建系统，如 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 文件中。

这是处理这类事情的通常方式吗？看起来有点麻烦，所以我想知道是否有更好的解决方案。

Answer 1

基本上有两种处理方式的选择。

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

当然，如果你想要完全通用的话，就这些了。<​​/p>

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

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

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

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