建议在Linux下进行符合FHS标准的应用程序测试/安装工作流？

Question

我正在转换到Linux进行开发的过程中，我对如何在我的程序中保持良好的FHS遵从性感到困惑。

例如，在Windows下，我知道所有资源(位图、音频数据等)我的程序所需要的文件可以在可执行文件的相对路径中找到，所以如果我从我的开发目录或安装目录(例如在"Program Files“下)运行程序，那么程序将能够找到它的所有文件。

现在，在Linux下，我看到可执行文件通常放在/usr/local/bin下，它的资源放在/usr/local/share下。(事实是，我甚至不确定这一点)

出于方便的原因(比如版本控制)，我希望所有与项目相关的文件都在同一路径下，例如，源文件的project/src和资源文件的project/data。

有没有什么标准或推荐的方法可以让我只重建二进制文件以进行测试，并使用project/data目录中的文件，同时还能够在文件位于/usr/local/share下时找到它们？

例如，我想在/usr/local/share下设置一个指向我的资源目录的符号链接，然后在我的程序中对该路径进行硬编码，但我觉得这样做很麻烦，而且不太便于移植。

此外，我还想运行一个安装脚本，在每次更改或添加资源时将所有资源复制到/usr/local/share，但我也觉得这不是一个好方法。

谁能告诉我或者告诉我这个问题通常是如何解决的？

谢谢!

Answer 1

为了方便起见(例如版本控制)，我希望项目的所有文件都在同一路径下，例如，源文件的

/src和资源文件的项目/数据。

你可以随心所欲地组织你的源码树--它不需要与已安装软件所需的FHS布局有任何相似之处。

我发现通常可执行文件放在/usr/

/bin下，它的资源放在/usr/local/share下。(事实是，我甚至不确定这一点)

标准前缀是/usr。正如/usr/local规范所重申的，FHS是用于“本地安装”的。

有没有什么标准或推荐的方法可以让我重新构建二进制文件以进行测试，并使用项目/data目录中的文件

一定。例如，运行./configure --datadir=$PWD/share可以将构建指向数据文件，形成源码树(替换为正确的路径)，并在AM_CFLAGS中使用类似-DDATADIR="'${datadir}'"的东西来使值为(假设是C)代码所知。(所有这些，只要你使用的是autoconf/automake。类似的选项可能在其他构建系统中可用。)

这种硬编码就是在实践中使用的，而且它已经足够了。对于您自己的工作副本中的开发构建，拥有硬编码路径应该不是问题，而最终构建(由打包者完成的构建)将简单地使用标准的FHS路径。

Answer 2

您可以只测试几个位置。例如，首先检查当前运行程序的目录中是否有data目录。如果是这样，那就使用它吧。如果没有，请尝试/usr/local/share/yourproject/data，以此类推。

对于开发/测试，您可以使用项目文件夹中的data目录，而对于部署，可以使用/usr/local/share/中的内容。当然，你可以测试更多的位置(例如/usr/share)。

基本上，此方法的要求是您有一个函数可以为所有文件系统访问构建正确的路径。使用类似fopen(path("blabla.conf"), "w")的代码而不是fopen("data/blabla.conf", "w")。path()将从程序启动时使用目录测试确定的路径构造正确的路径。例如，如果路径是/usr/local/share/yourproject/data/，那么path("blabla.conf")返回的字符串就是"/usr/local/share/yourproject/data/blabla.conf" --这就是你想要的绝对路径。

我就是这么做的。HTH。

Answer 3

在这种情况下，我的首选解决方案是使用配置文件，以及覆盖其位置的命令行选项。

例如，一个名为myapp的完全部署的应用程序的配置文件可以驻留在/etc/myapp/settings.conf中，其中的一部分可能如下所示：

...
confdir=/etc/myapp/
bindir=/usr/bin/
datadir=/usr/share/myapp/
docdir=/usr/share/doc/myapp/
...

您的应用程序(或启动器脚本)可以解析此文件，以确定在哪里可以找到所需的其余文件。

我相信您可以合理地在您的代码中假设配置文件的位置在/etc/myapp下是固定的-或者在编译时指定的任何其他位置。然后，您可以提供一个命令行选项以允许覆盖该位置：

myapp --configfile=/opt/myapp/etc/settings.conf ...

还可能有一些目录路径的选项，这样用户就可以轻松地覆盖任何配置文件设置。这种方法有几个优点：

• 您的用户可以非常轻松地重新定位应用程序-只需移动文件，修改配置文件中的路径，然后使用包装脚本使用适当的--configfile选项调用主应用程序。
• 您可以轻松支持FHS以及您需要的任何其他方案。
• 在开发时，您可以让您的测试套件使用一个特制的配置文件，路径位于您需要的任何位置。

有些人主张在运行时探查系统来解决这样的问题。我通常建议避免这样的解决方案，至少有以下原因：

• 它让你的程序变得不确定。你永远不会一眼就知道它拿起的是哪个配置文件--特别是如果你的系统上有多个版本的应用程序。
• 在任何安装错误的情况下，应用程序都会保持肥胖和快乐--用户也是如此。在我看来，应用程序应该查看一个记录良好的特定位置，如果找不到正在查找的内容，则中止并显示一条信息性消息。
• 您不太可能总是万无一失。
• 这样的行为与Unix哲学背道而驰。甚至comamnd shell也会探测多个位置，因为所有位置都可以保存应该解析的文件。

编辑：

据我所知，这种方法没有任何正式的标准要求，但它是Unix世界中流行的解决方案。大多数主要的守护进程(例如BIND、sendmail、postfix、INN、Apache)将在某个位置查找配置文件，但允许您覆盖该位置并通过该文件覆盖任何其他路径。

这主要是为了允许系统管理员实现他们想要的任何方案或设置多个并发安装，但它在测试期间也有帮助。这种灵活性使其即使不是适当的标准，也是最佳实践。