我有一个用C ++编写的游戏引擎。我有自己的“开发”GUI。该程序在日本销售，我有一个日本出版商，已经编写了一个商业GUI加入我的游戏引擎。我们已经安排了很多年。我的引擎和他的GUI都很大，很复杂，并且在发行版之间经常进行更改。当我的发行商想要一个新版本时，我会将他的源文件发送给他，然后他将与他的GUI一起编译，他的GUI将在我的引擎中调用一组预先安排的函数。似乎每次我们经历这个过程时，我们总会被一个或两个编译器标志绊倒，而不是我的。如果我们都使用相同的语言并且处于相同的时区，这将是一个非常小的问题，但是我们不这样做，即使是最小的问题也可能导致严重的问题和延迟。
有人建议如果我发给他一个图书馆而不是来源，那么这会减少错误的机会，而有人说我应该把他的项目文件发给他......我不太确定赞成和赞成。
是否有人提出任何建议或建议，以尽量减少此过程中出现故障的风险。有没有什么方法可以进行运行时/编译时检查以确保所有的编译和链接选项都符合预期？
编辑：刚刚注意到有关在GCC中记录编译器标志的this问题。似乎GNU允许这样做。是否有与visual studio相同的命令？
答案 0 :(得分：3)
我想说这对所有这些代码对编译器设置的敏感程度实际上有点令人惊讶。您知道您在日本的出版商是否将您的代码编译到库中，或者直接将其编译到主GUI中？如果它们需要不同的编译器标志，它们当然不应该在Visual Studio中的同一个项目中编译它们。
如果这是C ++，您可以使用boost's static assert来确保设置某些内容，如果没有设置，您可能还应该在地方添加一些#error宏。
话虽如此，我会向他们发送DLL和头文件。无论他们如何设置编译器标志，这都应该有效。
编辑此外，根据您的游戏内容，您可能会建议使用可以使用JSON，XML，ASN.1定义的协议将深度调用替换为引擎。或者你自己的语法 - 如果你的游戏没有硬核实时GUI要求，那就是。在这种情况下，界面变得微不足道，并且很难打破诸如错误的链接标记之类的东西。
答案 1 :(得分：1)
尽可能将GUI与引擎分开。理想情况下，GUI应位于一个单独的库中，如果切换GUI，则只应重新编译该库。
一个好的，广泛使用的解决方案是使用脚本语言分离GUI，Lua通常用于此目的。
在Windows下，完美的解决方案是以这样的方式拆分GUI，替换dll会改变GUI本身。有关使用dll提供模块化子系统的示例，请参阅OGRE。