在撰写本文时，还没有公认的解决方案可以处理您想要的一切。如果所有其他项目都在使用 CMake ，CMake 为您提供了跨平台构建，而 git（带有子模块）为您提供了一种管理源级依赖项的方法。但是，在实践中，您项目需要的许多常见依赖项不需要使用 CMake，甚至不需要使用 Git。
Ryppl 旨在解决这个问题，但进展缓慢，因为挑战如此艰巨。
可以说，迄今为止最成功的解决方案是编写仅标头库。这是常见的做法，意味着您的用户只包含您的文件，他们选择的构建系统会处理所有事情。没有要管理的二进制依赖项。
TheHouse 的回答基本上仍然是正确的。此外，ryppl 本身似乎有一段时间（3 年）没有任何更新，并且 ryppl.org 域已过期。
有一些新项目旨在解决包装问题。mesonbuild的build2和wrap都有这个目标。
最近提出了一项提议，将包添加到 c++ 标准中，这可能会引发争论（此处为 reddit 讨论）。
Wrap 看起来很有希望，因为 meson 的作者从 cmake 中学到了。当它的作者在这里讨论这个时，有一个很好的视频。build2 似乎更加健忘（因此注定要重新发明）。然而，两者都试图在提供完整构建系统的同时解决外部项目依赖问题。 conan.io是最近的另一个尝试，它也没有尝试提供构建系统。时间会证明这些是否有任何吸引力。
在 Unix 上打包 C 和 C++ 项目的公认标准始终是源 tarball + 配置脚本（autotools）+ make。cmake 现在开始取代 autotools 作为您的首选。它能够为分发目的创建 RPM 和 tarball。
它也值得考虑内置于各种 Linux 风格的包管理器。最容易构建和安装的项目是可以通过yum或apt引入大部分依赖项的项目。这当然不会帮助你在 Windows 上。虽然将自己的项目添加到主要的 Linux 存储库（例如 RedHat、Debian）有很高的进入门槛，但没有什么可以阻止您添加维护自己的卫星存储库。这与仅将项目托管在 github 或类似网站上的区别在于，您可以为许多流行的系统提供预构建的二进制文件。
您可能还会考虑配置时间检查（例如来自 cmake findLibrary()）和您自己的文档将告诉人们需要安装什么作为先决条件，并且只要您不要让它过于繁重就足够了。