我目前正在研究一个持续集成服务器的良好设置，该服务器将为多个 Linux 发行版构建各种 C++ 应用程序。
我的主要问题是这里的其他用户如何处理 Linux 发行版之间系统库的差异？
虽然与应用程序一起构建直接依赖项（例如 UI 库）可能相对容易，但如果每次都必须与应用程序一起构建“间接”依赖项（例如 glibc），它们看起来会很痛苦。因此，我正在考虑将实际构建执行移动到每个发行版的单独虚拟机中，例如使用 rlogin 来运行命令。我的目标是防止构建机器库版本与目标发行版中部署的库版本之间存在二进制不兼容性。
这里有没有人对这样的过程有任何经验，并且可以判断上述方法是否可行？
为此，我们使用Jenkins（连续集成）和CMake（构建系统）。Jenkins 类似于 Buildbot，即它也有 buildmaster 和 buildslaves。目前我已经为 4 个不同的平台（FC8、FC10、FC12 和 Windows 7）设置了 8 个从站。我们同时构建调试和发布二进制文件，因此我为每个平台和构建类型专用了一个从属。
至于像 Qt & Boost 这样的第三方库，我在每个平台上编译它们并检查它们到一个单独的存储库中。
@esavard：我们使用 CMake 2.8 进行交叉编译，我没有使用 minigw，但快速谷歌搜索表明这是可能的。这是使用 CMake 和 miniGW 在 Linux 上为 Windows 进行交叉编译的教程的链接。
我没有使用过 Buildbot，也无法评论它的功能，但我认为我应该提到我们目前正在使用的替代方案。
希望这可以帮助。
Buildbot有buildmasters 和 buildslaves的概念。
buildmaster 负责显示 Web GUI、发送电子邮件、触发构建和其他内务处理。buildslaves 等待 buildmaster 并在收到命令时执行构建。
我们已经将 buildbot 设置为在许多不同的平台上构建，其中一些是虚拟机，它对我们来说运行良好。
当然 buildbot 和许多虚拟机是解决这个问题的方法。我们有 VMWare ESX 服务器托管许多构建从属服务器，它们可以在一夜之间编译我们的应用程序。然后在另一台虚拟机上测试应用程序（不是构建从属机，只是安装了默认操作系统），以验证它是否工作并且所有依赖项都已打包。
我想做的一件好事是使测试运行时阶段成为一个自动化步骤，但我还没有时间去做。