为各种Linux桌面系统开发

Question

我还没有为Linux操作系统开发任何生产应用程序。有几件事困扰着我：

• 据我所知，不同的发行版有不同的库集。
• Debian vs RPM软件包
• 不同的UI - Gnome vs KDE

人们如何处理所有这些差异？有没有办法从这些差异中抽象化？(顺便说一句。我漏掉了什么吗？)

Answer 1

当然，你错过了一些可能性--开源软件的诅咒和祝福是，任何人都可以创建自己的备选方案，而且很多人都可以这样做--但你已经列出了最重要的平台和发行格式。

那么，你怎样做才能尽可能地兼容呢？有两个广泛的选择。第一种方法是分发带有编译指令的源代码。这意味着您不需要处理这些问题，但是每个想要使用您的软件的人都必须自己编译。这在原则上是容易的，但在实践中，这相当于前提条件，即您的用户要么拥有与您完全相同的设置，要么他们学习如何在正确的版本中获取和编译所有必要的依赖项。这变得更加困难，你的软件越复杂，而且不管怎么说，许多用户，即使是Linux的用户，都不愿意自己编译东西，因为他们认为这是低层次和困难的。

二是成为图书馆的一员。这意味着要遵守一些打包约定并复制一些工作，既可以遵循几种打包格式，也可以为每个新OS版本保持最新状态，但这意味着任何可能的用户只需要在他们的软件包管理器中搜索(希望是，令人难忘和信息丰富的)您的软件的名称，然后单击“是”。如果你想要任何形式的非极客市场的渗透，这是一条路。

我要补充的是，您可以遵循(当然)无数的变体和混合策略。例如，你的目标是成为一个非官方的软件包。这基本上意味着你希望别人会喜欢你的软件来安装它，他们会制作一个RPM或APT软件包并与其他人分享(当然，如果你愿意的话，你可以鼓励甚至帮助他们)。这意味着第三方用户只需注册一个额外的存储库，搜索您的软件，然后单击“是”。权衡的结果与您预期的完全相同:您仍然需要多次这样做，而且结果只对一个特定的目标有效，但是大部分工作是由其他人完成的。

Answer 2

我们在工作的时候就这么做。我们不想分发源代码，所以只有二进制发行版才是唯一的选择。我们解决这个共享库版本问题的方法是静态地链接大多数库。(例外: libc是动态链接的。)可以将单个库指定为/full/path/to/library.a。请注意，静态库的链接顺序比动态库的链接顺序更重要。还请注意，/full/path/to库在不同发行版之间可能有所不同。在我们的示例中，完整的路径是makefile中的一个可配置选项(出于许多原因，我们不使用GNU自动工具)。另外，请注意，CentOS、RHEL和Fedora不提供静态链接库，这是由于乌尔里希·德雷珀的意见。因此，编译机器不能使用此列表中的操作系统。当然，编译后的二进制文件可以在CentOS、RHEL和Fedora上运行。

.deb与.rpm问题是以tar.gz作为分发包来解决的。您只需将其解压缩到需要二进制文件的目录中，然后启动程序。本例中的所有库都是静态链接的，因此我们的分发包中没有.so文件。因此，LD_LIBRARY_PATH环境变量是不必要的。

我们的图形用户界面实际上既不构建在GTK上，也不构建在QT上。它使用Java。这也是一种可以考虑用于其他应用程序的方法。Java的好处是GUI也可以在Windows机器上运行。

如果您想要构建一个GUI应用程序，并且没有特别的理由使用C或C++作为语言，我建议您仔细考虑一些基于JVM的语言。这意味着您的应用程序在Windows上也很有用。在我们的例子中，我们需要使用主程序中的原始套接字来处理高性能的原始网络数据包，所以它必须使用C(或C++)来实现。但是GUI是一个独立的Java应用程序。

另外，现在有些人使用Python等语言来实现GUI。这也是一个值得考虑的选择。Python和Java都没有因为指针使用无效而导致内存损坏，因此从这个意义上说，它们显然优于C和C++。但是，请注意，使用Python意味着您必须交付源代码。

Answer 3

库的两种方法& UI问题：

1. 将自己限制在所针对的平台之间的最低公共分母。请记住，不同的桌面可以彼此运行应用程序，但不一定看起来是本地的。
2. 安装您正在使用的特定库/UI，这是您的软件的先决条件。一个例子可能是使用wxWidgets或QT库，这两个库都以不同的方式针对多个UI。

对于打包和分发方面的东西，您只需要以多种方式捆绑您的软件，并安排以适当的方式分发它们(S)--在主从安排中使用脚本或Jenkins。

您还需要解决在多个linux平台上进行测试的问题--在这方面，Docker和Travis等工具是您的朋友。