使用CMake和Ryppl的C ++库生态系统

Question

我有兴趣构建一个跨平台的C ++库并以源代码形式分发它。我希望这个库的消费者能够获得它，构建它并在他们正在使用的任何平台上以及他们所针对的任何平台上非常容易地在其软件中使用它。在构建我的库的同时，我也希望能够通过类似的机制使用其他流行的OSS库。

我看到CMake和Ryppl是在考虑到这些意图的情况下创建的，并且在某种程度上它们确实解决了其中一些问题，尤其是构建问题。但我不太清楚如何实现上述目标。是否可以将CMake作为构建解决方案来解决？如何解决图书馆采集和发布问题？只需在某处托管源代码，让人们发现，下载和构建它们？或者有更好的方法吗？

Answer 1

在撰写本文时，没有可接受的解决方案可以处理您想要的所有内容。 CMake为您提供跨平台构建，如果所有其他项目都使用CMake，git（带子模块）为您提供了一种管理源级别依赖项的方法。但是，在实践中，你投射的许多常见依赖关系都不需要使用CMake，甚至不需要使用Git。

Ryppl旨在解决这个问题，但进展缓慢，因为挑战是如此艰难。

可以说，到目前为止最成功的解决方案是编写仅限标头的库。这是常见的做法，意味着您的用户只需包含您的文件，并且他们选择的构建系统可以解决这些问题。没有二进制依赖项可以管理。

Answer 2

TheHouse的回答基本上仍然是正确的。 ryppl本身似乎没有任何更新（3年），ryppl.org域已经过期。

有一些新项目旨在解决包装问题。 来自mesonbuild的build2和wrap都考虑到了这一目标。

最近发布proposal来向c ++标准添加包，这可能会引发争论（reddit discussion here）。

Wrap看起来很有前途，因为meson的作者从cmake那里学到了东西。 当作者讨论这个问题时，有一段很好的视频here。 build2似乎更无视（因此被谴责重新发明）。然而，两者都试图在提供完整的构建系统的同时解决外部项目依赖性问题。 conan.io是最近的另一次尝试，它不会尝试提供构建系统。时间将证明这些是否有任何牵引力。

在Unix上打包C和C ++项目的公认标准始终是源tarball +配置脚本（autotools）+ make。 cmake现在开始取代autotools作为您的首选。 它可以为分发目的创建RPM和tarball。

它还值得考虑内置于各种Linux版本的软件包管理器。最容易构建和安装项目的是那些可以通过 yum 或 apt 引入大多数依赖项的项目。当然，这对窗户没有帮助。虽然进入主要Linux存储库（例如RedHat，Debian）的项目存在很高的障碍，但没有什么可以阻止您添加维护自己的卫星存储库。 只需在github上或类似地托管您的项目，您可以为许多流行的系统提供预先构建的二进制文件。

您可能还会考虑配置时间检查（例如来自cmake findLibrary（）），您自己的文档会告诉人们需要安装什么作为先决条件，并提供您不要这可能就足够了。