xmake
xmake copied to clipboard
xmake-io
cmake不应使用系统默认的工具链
Xmake 版本
v2.7.9+dev.8b9228762
操作系统版本和架构
Windows11 21H2
描述问题
在构建包时，xmake已经将工具链设置成了gcc
in xmake-repo:
-> benchmark 1.8.0 [toolchains:"gcc", vs_runtime:"MT", shared:n]
但编译的时候用的是msvc
-- Check for working CXX compiler: D:/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe
那编译出来的库肯定用不了，会产生链接错误。
期待的结果
使用设置的工具链去编译依赖库，而不是用平台默认的。 建议将ninja设置为默认，因为ninja支持多个平台并且轻量而快速。相较于Windows下的msbuild，ninja的效果会更好。
工程配置
No response
附加信息和错误日志
> g++ -o C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.b C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o -m64 -LC:\Users\22835\AppData\Local\.xmake\packages\b\benchmark\1.8.0\15d21182b5c34f69adcf4c498c0aaf92\lib -lbenchmark_main -lbenchmark -lshlwapi
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x61): undefined reference to `benchmark::State::StartKeepRunning()'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x11d): undefined reference to `benchmark::State::FinishKeepRunning()'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x169): undefined reference to `benchmark::internal::InitializeStreams()'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x1c8): undefined reference to `benchmark::internal::RegisterBenchmarkInternal(benchmark::internal::Benchmark*)'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x241): undefined reference to `benchmark::internal::RegisterBenchmarkInternal(benchmark::internal::Benchmark*)'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text+0x249): undefined reference to `benchmark::internal::Benchmark::ThreadPerCpu()'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.text$_ZN9benchmark8internal17FunctionBenchmarkC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFvRNS_5StateEE[_ZN9benchmark8internal17FunctionBenchmarkC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFvRNS_5StateEE]+0x20): undefined reference to `benchmark::internal::Benchmark::Benchmark(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
D:/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.1.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\22835\AppData\Local\Temp\.xmake\230622\_2C71A5DB5AD14F2081A38BC034C61A90.o:_CD0CDFD16296488DBA3A516F729ED0EC.cpp:(.rdata$.refptr._ZTVN9benchmark8internal17FunctionBenchmarkE[.refptr._ZTVN9benchmark8internal17FunctionBenchmarkE]+0x0): undefined reference to `vtable for benchmark::internal::FunctionBenchmark'
collect2.exe: error: ld returned 1 exit status
可以看到链接错误了。
Bot detected the issue body's language is not English, translate it automatically.
Title: cmake should not use the system default toolchain
? 你怎么设置平台的？如果是默认的 -p windows 平台，对于包，目前原本就是绑定 msvc toolchain ，不支持切换其他 toolchain 。。不管是否 cmake 。。其他 meson scons 等维护的包也不支持切换。。
因为包要在 ci 上做压测，一个 msvc 就已经 shared/static/MT/MTd/MD/MDd/x64/x86 等全排列压测，并且 on_install 脚本要做各种适配，再去支持任意 toolchain 切，维护不过来， 工作量和组合数是数量级增长。。
而且绑定 msvc 的好处，除了测试和适配更完善，而且支持云端预编译，对 windows 包支持加速安装，要是在搞个 toolchain 切，很难搞。
要想对包切 toolchains ，走交叉编译，-p cross ，目前只有交叉编译的包 才支持任意 toolchain 切换。。-p linux 平台支持 gcc/clang 等 host toolchain 切换。。windows 平台，目前只有 xmake 维护的包，能支持 gcc/clang 切换，其他 cmake 维护的暂时不支持。
你怎么设置平台的？
就是-p windows
目前原本就是绑定 msvc toolchain ，不支持切换其他 toolchain。
但msvc的abi以及name mangling和gcc/clang不一样，就导致mingw用不了msvc编译的库。Linux至少都是gnu的，不会链接错误。
要想对包切 toolchains ，走交叉编译，-p cross ，目前只有交叉编译的包 才支持任意 toolchain 切换。
但不换平台只换工具链还是有意义的嘛，这个gcc/clang的优化也比msvc更好。而且benchmark这种不应该因为交叉编译有问题， 就不让mingw用了嘛。而且有一个小问题，windows下开-p cross会去找Unix Makefiles，这还是改用ninja好一点吧。
支持云端预编译，对 windows 包支持加速安装
那就toolchain是msvc的时候走预编译，其他时候还是编译安装。
Bot detected the issue body's language is not English, translate it automatically.
How did you set up the platform?
That's -p windows
At present, it is originally bound to the msvc toolchain, and switching to other toolchains is not supported.
However, the abi and name mangling of msvc are different from gcc/clang, which makes mingw unable to use the library compiled by msvc. Linux is at least gnu, and there will be no link errors.
If you want to switch toolchains for packages, use cross-compilation, -p cross. Currently, only cross-compiled packages support arbitrary toolchain switching.
But it still makes sense to change the toolchain without changing the platform. The optimization of gcc/clang is better than msvc. And the benchmark should not be a problem because of cross-compilation, Do not let mingw use it. And there is a small problem. Opening -p cross under windows will find Unix Makefiles. It is better to use ninja instead.
Support cloud precompilation, and support accelerated installation for windows packages
Then the toolchain is pre-compiled when it is msvc, and compiled and installed at other times.
因为包要在 ci 上做压测，一个 msvc 就已经 shared/static/MT/MTd/MD/MDd/x64/x86 等全排列压测，并且 on_install 脚本要做各种适配
把Windows下的gcc/clang作为可选支持如何？不再做额外测试。能构建则构建，不能那是写库的人的问题。就只保证msvc能正常用。
Bot detected the issue body's language is not English, translate it automatically.
Because the package needs to be pressure tested on ci, a msvc already has a full array of pressure tests such as shared/static/MT/MTd/MD/MDd/x64/x86, and the on_install script needs various adaptations
How about optional support for gcc/clang under Windows? No additional testing is required. If you can build it, you can build it. If you can't, that's the problem of the person who wrote the library. It only ensures that msvc can be used normally.
你怎么设置平台的？
就是-p windows
目前原本就是绑定 msvc toolchain ，不支持切换其他 toolchain。
但msvc的abi以及name mangling和gcc/clang不一样，就导致mingw用不了msvc编译的库。Linux至少都是gnu的，不会链接错误。
mingw 有专门的 -p mingw 平台，以及对 mingw 支持的包，如果你要走 mingw ，应该直接切到 mingw 平台，而不是 window 平台下切工具链
要想对包切 toolchains ，走交叉编译，-p cross ，目前只有交叉编译的包 才支持任意 toolchain 切换。
但不换平台只换工具链还是有意义的嘛，这个gcc/clang的优化也比msvc更好。而且benchmark这种不应该因为交叉编译有问题
如果不用包，工具链随意切，用了包，对工具链切换肯定有限制的，不能让你随意切，
就不让mingw用了嘛。
mingw 有专门的 mingw 平
而且有一个小问题，windows下开-p cross会去找Unix Makefiles，这还是改用ninja好一点吧。
看包用的构建工具，cmake 的。包里面可以选择性切到 ninja 去编译，可以自己改。。
支持云端预编译，对 windows 包支持加速安装
那就toolchain是msvc的时候走预编译，其他时候还是编译安装。
支持不了，每个 target 编译，不单纯仅有一个 toolchain，有可能 msvc ,yasm, dlang 等多个 toolchain 同时生效来混编，单纯从 Toolchain 层面处理预编译，不好搞，而且 linux macos 等平台还得收到 平台的 系统版本，runtime lib 等影响。。。单靠 toolchain 不行。。。只有 平台强绑定 才能更可靠的处理，实现起来相对也比较简单 好维护。
因为包要在 ci 上做压测，一个 msvc 就已经 shared/static/MT/MTd/MD/MDd/x64/x86 等全排列压测，并且 on_install 脚本要做各种适配
把Windows下的gcc/clang作为可选支持如何？不再做额外测试。能构建则构建，不能那是写库的人的问题。就只保证msvc能正常用。
目前仅 xmake 维护的包支持，其他 cmake autoconf meson 包暂时不支持
Bot detected the issue body's language is not English, translate it automatically.
How did you set up the platform?
is -p windows
At present, it is originally bound to the msvc toolchain, and switching to other toolchains is not supported.
But the abi and name mangling of msvc are different from gcc/clang, which makes mingw unable to use the library compiled by msvc. Linux is at least gnu, and there will be no link errors.
mingw has a dedicated -p mingw platform and packages that support mingw. If you want to use mingw, you should directly switch to the mingw platform instead of cutting the toolchain under the window platform
If you want to switch toolchains for packages, use cross-compilation, -p cross, currently only cross-compiled packages support arbitrary toolchain switching.
But it still makes sense to change the toolchain without changing the platform. The optimization of gcc/clang is better than msvc. And the benchmark should not be a problem because of cross-compilation
If you don’t use the package, you can switch the tool chain at will. If you use the package, there must be restrictions on switching the tool chain, and you can’t switch it at will.
Do not let mingw use it.
mingw has a dedicated mingw ping
And there is a small problem. Opening -p cross under windows will find Unix Makefiles. It is better to switch to ninja.
Look at the build tool used by the package, cmake. In the package, you can selectively switch to ninja to compile, and you can change it yourself. .
Support cloud precompilation, and support accelerated installation for windows packages
Then the toolchain is pre-compiled when it is msvc, and compiled and installed at other times.
It can’t be supported. Compiling each target requires not only one toolchain, but multiple toolchains such as msvc, yasm, and dlang may take effect at the same time for mixed compilation. It is not easy to process precompilation from the Toolchain level, and platforms such as linux macos are still It must be affected by the system version of the platform, runtime lib, etc. . . Toolchain alone will not work. . . Only with strong platform binding can it be processed more reliably, and it is relatively simple to implement and easy to maintain.
Bot detected the issue body's language is not English, translate it automatically.
Because the package needs to be pressure tested on ci, a msvc has already been fully arranged for pressure testing such as shared/static/MT/MTd/MD/MDd/x64/x86, and the on_install script needs to do various adaptations
How about optional support for gcc/clang under Windows? No additional testing is required. If you can build it, you can build it. If you can't, that's the problem of the person who wrote the library. It only ensures that msvc can be used normally.
Currently only the packages maintained by xmake are supported, other cmake autoconf meson packages are not supported temporarily
尽管理论上，随意切换 toolchain 肯定能实现，但是要考虑到现在，我单人的维护成本，时间，实现复杂度 等各方面综合考虑。。也许将来可能会支持，但短期你只能强绑定 windows 平台走 msvc 的包，mingw 平台走 mingw 包，cross 平台，走任意 toolchain 包。
Bot detected the issue body's language is not English, translate it automatically.
Although in theory, it is definitely possible to switch the toolchain at will, but now, I have to consider the maintenance cost, time, implementation complexity and other aspects of my single person. . Maybe it will be supported in the future, but in the short term you can only strongly bind the windows platform and use the msvc package.
另外，windows 随意切 toolchain 。。还会导致 xmake-repo 里面每个 包的 配置脚本，on_install 脚本，额外增加脚本复杂度，降低可维护性，也会导致贡献者更难维护和改进包脚本。。
原本 windows 的包，我只需要简单假定作为 msvc 编译的来处理，安装脚本会很简单，维护性很好，现在额外多出 gcc/clang 等 N 中可能性， on_install 脚本里得额外判断 当前处于哪个 toolchian ，加特殊的安装逻辑，patch 逻辑，配置逻辑。。会很蛋疼。
Bot detected the issue body's language is not English, translate it automatically.
In addition, windows cuts the toolchain at will. . It will also cause configuration scripts and on_install scripts for each package in xmake-repo, which will add additional script complexity and reduce maintainability, and will also make it more difficult for contributors to maintain and improve package scripts. .
The original windows package, I only need to simply assume that it is compiled as msvc, the installation script will be very simple, and the maintainability is very good. Now there are additional N possibilities such as gcc/clang, and the on_install script must additionally judge which one it is currently in. toolchian, plus special installation logic, patch logic, configuration logic. . It will be a pain in the ass.
原本 windows 的包，我只需要简单假定作为 msvc 编译的来处理，安装脚本会很简单，维护性很好，现在额外多出 gcc/clang 等 N 中可能性， on_install 脚本里得额外判断 当前处于哪个 toolchian ，加特殊的安装逻辑，patch 逻辑，配置逻辑。。会很蛋疼。
我认为可以放宽对本地的包的约束。xmake-repo的包依然严格和msvc绑定，而由用户创建的本地包则允许任意工具链，由用户去维护，这样就能比较好得解决这个问题了。毕竟用户可以知道他到底需要哪些组合而不用一一测试。
原本 windows 的包，我只需要简单假定作为 msvc 编译的来处理，安装脚本会很简单，维护性很好，现在额外多出 gcc/clang 等 N 中可能性， on_install 脚本里得额外判断 当前处于哪个 toolchian ，加特殊的安装逻辑，patch 逻辑，配置逻辑。。会很蛋疼。
我认为可以放宽对本地的包的约束。xmake-repo的包依然严格和msvc绑定，而由用户创建的本地包则允许任意工具链，由用户去维护，这样就能比较好得解决这个问题了。毕竟用户可以知道他到底需要哪些组合而不用一一测试。
不是限制问题，是支持复杂度问题，目前还没人力实现，就算本地要支持，也得对 cmake/meson 透传 toolchain 环境，预编译对 toolchain加各种逻辑 过滤掉 gcc/clang 等非 msvc ，还要解决各种透传后，遇到的细节问题。。各种地方都要改。。没那么简单。。都要花大量时间人力，才能支持上的。。。不是单纯一句像放开 就能放开的。。
单 cmake 在 linux 下，我透传一个 clang toolchain ，陆陆续续迭代了这么多版本，还有不少细节东西，要处理，趟了不少 cmake 的坑，更别提还有 meson scons 等构建工具的包，透传的支持，又是一大堆逻辑处理
Bot detected the issue body's language is not English, translate it automatically.
The original windows package, I only need to simply assume that it is compiled by msvc, the installation script will be very simple, and the maintainability is very good. Now there are additional possibilities such as gcc/clang, etc., and the on_install script must additionally judge the current status Which toolchian, plus special installation logic, patch logic, configuration logic. . It will be a pain in the ass.
I think it's possible to loosen the constraints on local packages. The xmake-repo package is still strictly bound to msvc, while the local package created by the user allows any tool chain to be maintained by the user, so that this problem can be better solved. After all, the user can know which combinations he really needs without having to test them one by one.
Bot detected the issue body's language is not English, translate it automatically.
The original windows package, I only need to simply assume that it is compiled as msvc, the installation script will be very simple, and the maintainability is very good. Now there are N possibilities such as gcc/clang, and the on_install script has to judge the current In which toolchian, add special installation logic, patch logic, configuration logic. . It will be a pain in the ass.
I think the constraints on local packages can be relaxed. The xmake-repo package is still strictly bound to msvc, while the local package created by the user allows any tool chain to be maintained by the user, which can solve this problem better. After all, the user can know which combinations he really needs without having to test them one by one.
It is not a limitation issue, but a support complexity issue. At present, it has not been implemented by manpower. Even if local support is required, the toolchain environment must be transparently transmitted to cmake/meson, pre-compiled and various logics are added to the toolchain to filter out non-msvc such as gcc/clang. . Various places have to be changed. . not that simple. . It takes a lot of time and manpower to support it. . . It's not something that can be let go with a simple sentence like let go. .
尽管理论上，随意切换 toolchain 肯定能实现，但是要考虑到现在，我单人的维护成本，时间，实现复杂度 等各方面综合考虑。。也许将来可能会支持，但短期你只能强绑定 windows 平台走 msvc 的包，mingw 平台走 mingw 包，cross 平台，走任意 toolchain 包。
哥们，你这不容易啊，单人维护这么多年
Bot detected the issue body's language is not English, translate it automatically.
Although in theory, it is definitely possible to switch toolchains at will, but now, I have to take into account the maintenance cost, time, implementation complexity and other aspects of my single person. . Maybe it may be supported in the future, but in the short term you can only strongly bind the windows platform to use the msvc package, the mingw platform to use the mingw package, and the cross platform to use any toolchain package.
Brother, it's not easy for you. You have been maintaining it alone for so many years.