我们有大量的核心库和基于这些库的应用程序。我们为每个项目或库使用 Visual Studio 解决方案在 Linux 和 Windows 上维护基于 Makefile 的构建系统。
我们发现它可以很好地满足我们的需求，每个库或应用程序都是在 linux 或 windows 上开发的，并考虑了交叉编译（例如，不要使用特定于平台的 api）。我们将 boost 用于文件路径、线程等。在特定情况下，我们使用模板/#defines 来选择特定于平台的解决方案（例如事件）。准备就绪后，我们移至其他系统（linux 或 windows），重新编译，修复警告/错误并进行测试。
我们没有花时间找出可以在两个平台上交叉编译的工具，而是使用最适合每个平台的系统，并花时间修复特定问题并使软件变得更好。
我们仅在 Windows atm 上有 GUI 应用程序。所以没有交叉编译的GUI。我们在 Windows 和 Linux 之间共享的大部分开发是服务器端网络（套接字、TCP/IP、UDP ...），然后是 Linux 上的客户端工具和 Windows 上的 GUI 应用程序。
使用 perforce 进行源代码版本管理，我们发现在很多情况下 Linux Makefile 系统比 Windows VS 更灵活地满足我们的需求。特别是对于使用多个工作区（源代码版本的视图），我们需要指向公共目录等。在 Linux 上，这可以通过自动运行脚本来更新环境变量来完成，在 Visual Studio 上引用环境变量非常不灵活，因为很难在视图/分支之间自动更新。
重新同步问题：
我假设您在问如何确保两个构建系统在 linux 和 windows 之间同步。我们实际上在 Linux 上使用 Hudson，在 Windows 上使用 CruiseControl（我们首先在 Windows 上使用巡航控制，当我去设置 linux 版本时，我认为 Hudson 更好，所以现在我们有了混合环境）。我们的系统一直在运行。当某些东西被更新时，它会被测试和发布（无论是 windows 还是 linux 版本），所以你会马上知道它是否不起作用。在测试期间，我们确保所有最新功能都在那里并且功能齐全。我想就是这样，不涉及黑魔法。
哦，你的意思是构建脚本......每个应用程序都有自己的解决方案，在解决方案中设置依赖项。在 Linux 方面，我为每个项目都有一个 makefile，并且在项目目录中有一个构建脚本来处理所有依赖项，这主要意味着构建核心库和给定应用程序所需的几个特定框架。正如您所看到的，这对于每个平台都是不同的，很容易添加行来构建脚本来更改目录并制作所需的项目。
它有助于以一致的方式设置项目。
在 Windows 上，您打开项目并添加依赖项项目。再次没有涉及魔法。我认为这类任务与开发相关，例如您向项目添加了新功能并且必须链接到框架和标题中。因此，从我的角度来看，没有理由将这些自动化 - 因为它们是开发人员在实现功能时所做的一部分。