默认的tinyxml.lib 是32位的，但是cmake出来的项目是64位的，这编不过啊

[zhangzidan]

默认的tinyxml.lib 是32位的，但是cmake出来的项目是64位的，这编不过啊

[nmgwddj]

使用 cmake 命令 cmake -Bbuild -G"Visual Studio 15 2017" -T"v141_xp" -DCMAKE_BUILD_TYPE=Debug 生成工程时如果 generator 是 VS 2017，默认生成的工程一定是 32 位的。 而新版本的 generator 默认才是 64 位的。使用 Visual Studio IDE 打开解决方案时确认选择的是 32 位编译任务。如果您确认 generator 是 VS 2017 并且生成的工程只有 64 位没有 32 位的，可在命令中增加参数来控制生成的工程配置：

cmake -G "Visual Studio 15 2017" -A Win32
cmake -G "Visual Studio 15 2017" -A x64
cmake -G "Visual Studio 15 2017" -A ARM
cmake -G "Visual Studio 15 2017" -A ARM64

cmake 参考文档：https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html

[idoop]

使用 cmake 命令 cmake -Bbuild -G"Visual Studio 15 2017" -T"v141_xp" -DCMAKE_BUILD_TYPE=Debug 生成工程时如果 generator 是 VS 2017，默认生成的工程一定是 32 位的。 而新版本的 generator 默认才是 64 位的。使用 Visual Studio IDE 打开解决方案时确认选择的是 32 位编译任务。如果您确认 generator 是 VS 2017 并且生成的工程只有 64 位没有 32 位的，可在命令中增加参数来控制生成的工程配置：

cmake -G "Visual Studio 15 2017" -A Win32
cmake -G "Visual Studio 15 2017" -A x64
cmake -G "Visual Studio 15 2017" -A ARM
cmake -G "Visual Studio 15 2017" -A ARM64

cmake 参考文档：https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html

都2023年了，支持64位的构建很难吗？

[nmgwddj]

使用 cmake 命令 cmake -Bbuild -G"Visual Studio 15 2017" -T"v141_xp" -DCMAKE_BUILD_TYPE=Debug 生成工程时如果 generator 是 VS 2017，默认生成的工程一定是 32 位的。 而新版本的 generator 默认才是 64 位的。使用 Visual Studio IDE 打开解决方案时确认选择的是 32 位编译任务。如果您确认 generator 是 VS 2017 并且生成的工程只有 64 位没有 32 位的，可在命令中增加参数来控制生成的工程配置：

cmake -G "Visual Studio 15 2017" -A Win32
cmake -G "Visual Studio 15 2017" -A x64
cmake -G "Visual Studio 15 2017" -A ARM
cmake -G "Visual Studio 15 2017" -A ARM64

cmake 参考文档：https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html

都2023年了，支持64位的构建很难吗？

感谢您的反馈，我们会在近期完整支持 64 位编译。 工程实际很早就支持 64 位的编译，但历史的工程管理方式全部将与编译的库文件上传到 github 上，这会导致国内较多地区网络不佳（尤其是联通和移动网络）时很难 checkout 出代码。 因为这个原因，我们将依赖的三方库移动到了自己的平台提供编译时下载指定与编译库压缩包。虽然这解决了部分 checkout 代码的问题，但这样的维护成本依然很高，一旦某个库文件更新我们需要重新打包整个三方库的压缩包并重新上传，执行流程繁杂容易出错，所以仅维护了 32 位版本。 到目前为止，我们已经有了更合理的工程管理方案，会在近期进行更新。

[idoop]

使用 cmake 命令 cmake -Bbuild -G"Visual Studio 15 2017" -T"v141_xp" -DCMAKE_BUILD_TYPE=Debug 生成工程时如果 generator 是 VS 2017，默认生成的工程一定是 32 位的。 而新版本的 generator 默认才是 64 位的。使用 Visual Studio IDE 打开解决方案时确认选择的是 32 位编译任务。如果您确认 generator 是 VS 2017 并且生成的工程只有 64 位没有 32 位的，可在命令中增加参数来控制生成的工程配置：

cmake -G "Visual Studio 15 2017" -A Win32
cmake -G "Visual Studio 15 2017" -A x64
cmake -G "Visual Studio 15 2017" -A ARM
cmake -G "Visual Studio 15 2017" -A ARM64

cmake 参考文档：https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html

都2023年了，支持64位的构建很难吗？

感谢您的反馈，我们会在近期完整支持 64 位编译。 工程实际很早就支持 64 位的编译，但历史的工程管理方式全部将与编译的库文件上传到 github 上，这会导致国内较多地区网络不佳（尤其是联通和移动网络）时很难 checkout 出代码。 因为这个原因，我们将依赖的三方库移动到了自己的平台提供编译时下载指定与编译库压缩包。虽然这解决了部分 checkout 代码的问题，但这样的维护成本依然很高，一旦某个库文件更新我们需要重新打包整个三方库的压缩包并重新上传，执行流程繁杂容易出错，所以仅维护了 32 位版本。 到目前为止，我们已经有了更合理的工程管理方案，会在近期进行更新。

Nice。 但用户的网络你们这边其实完全可以不用考虑，毕竟大家都是程序员，只是上个代理拉代码，代码都拉不下来只能是自己的问题。 第三方库的依赖你们可以用 git submodule 集成或者用 cmake 的 FetchContent 集成，没必要自己构建完再打包分发。毕竟现在大家已经开始用 VS 2022了，每个开发者的开发环境也不可能都是一致的，因此从源码构建一劳永逸。