我们正在运行单元测试作为构建中的构建后步骤。现在我在我们的autobuild机器上遇到了这个问题，它自动在svn中提取和构建每个修订版。
autobuild脚本下拉修订版，进行一些设置，然后调用devenv.exe / build。反过来，这将构建所有内容，然后尝试运行测试。构建卡住了，永远不会完成。
如果手动构建解决方案，运行测试点会发生什么是弹出对话框，说明测试可执行文件不是有效的Win32应用程序。我假设autobuild以某种方式得到这个盒子，但隐藏在某个非交互式会话中。
到目前为止，我有两个解决方案的想法：
检入试图运行测试并检测到故障的测试运行器应用程序。这是不可取的，因为这意味着创建这些额外的代码并将其添加到仅在Windows构建等上使用。
以某种方式测试构建脚本中的Windows是32位还是64位（我们正在运行cmake），如果它们不起作用，就不要运行测试。这是首选，但需要一种方法来检查窗口是32位还是64位，最好不必检查另一个“test-windows-type”辅助工具。
非常感谢有关如何实施建议2的任何进一步的想法或提示。
更新：请注意：这是在32位计算机上运行的交叉编译，但编译的是64位exe。如果我只是检查编译器的属性，就不会有问题。但是我正在使用构建机器的属性，而不是构建本身的属性，这显然是64位。
答案 0 :(得分：1)
检查%PROCESSOR_ARCHITECTURE%环境变量：
x86在32位计算机上。AMD64（参见here）。答案 1 :(得分：0)
您应该能够检查我认为32/64位窗口不同的CMake生成器。
答案 2 :(得分：0)
您可以检查构建脚本中的CMAKE_SIZEOF_VOID_P变量以检测类型。请参阅文档here。然后，如果此变量为32，则可以跳过运行测试。
更新：抱歉，我忽略了您的真实问题。我认为最好的方法可能是应用try-run测试并使用RUN_RESULT_VAR来确定应用程序是否成功运行。
答案 3 :(得分：0)
不是你问的具体问题的答案，但你应该考虑在x64机器上构建你的应用程序，它可以运行32位测试以及64位测试......
答案 4 :(得分：0)
我发现了一种识别系统是否为64位的方法，应该可以从cmake访问。虽然可以在任何随机版本的Windows上破解，但感觉这是一个相当丑陋的黑客攻击，所以我仍然宁愿找到另一种方式。
％ProgramFiles（x86）％环境变量仅存在于64位操作系统版本中。