在可执行文件中使用GNU标准目录变量

Question

通常需要可执行文件中的一个标准GNU目录的位置。不幸的是，GNU autoconf没有提供标准的方法，但建议了几个解决方法，每个都有不同的缺点，访问安装位置的常用方法是在CPPFLAGS中添加预处理定义：

AM_CPPFLAGS = -DDATADIR='"$(datadir)"'

但是，defining directories的GNU Autoconf手册部分包含以下句子：

  

请注意，所有以前的解决方案都硬连接可执行文件中这些目录的绝对名称，这不是一个好的属性。您可以尝试计算相对于前缀的名称，并尝试在运行时查找前缀，这样您的包可以重定位。

是否有一个库或任何标准方法来计算可执行文件中的GNU目录，如引用段落中所述？与上面提到的预处理器定义相比，它会有其他缺点吗？

Answer 1

我认为文档对此非常清楚：标准方法是不对绝对路径做任何假设，而是使用相对路径。特别是你不应该对${prefix}

做任何假设

因此，如果您的应用需要访问共享数据，请通过../share/foo/foodata.txt访问它，而不是使用/usr/local/share/foo/foodata.txt;通过这种方式，您可以轻松地重新定位您的应用程序。

Afaik，根据您的调用二进制文件，没有外部库为您计算标准路径。

这可能有两个原因：

• 如果二进制文件确实使用标准路径，那么自己计算这些路径（使用相对路径）是微不足道的。图书馆会做得更好吗？

• 如果二进制文件不使用标准路径（例如，因为构建器使用了类似下面的内容（当然是假设的）示例），那么解析这些路径的任务实际上是不可能的;所以图书馆也无法帮助你

例如：

./configure --sbindir=/home/me/sbin --bindir=/opt/foo/bin
make pkglibdir=/usr/lib/goo/
make install libdir=/usr/local/foo/lib/

帮助程序库（或您的应用程序）可能会将所有这些路径记录到某个辅助文件中（如果标准路径失败，则进行其他查找），但我认为最大的问题是没有定义存储位置的地方文件

• libdir或datadir显然不太好（因为数据应该有助于解决这些路径，所以不能依赖它们）
• 将数据放入与应用程序二进制文件相同的目录中会打破bindir仅包含可执行文件的假设。
• 将数据放入应用程序二进制文件可能需要在make install期间修改二进制文件，这听起来也很脏。