Improve runtimes to support libc++/libstdc++ #4630
Conversation
waruqi
changed the title
|
这里复用不合适吧？unix的runtime处理和windows完全不一样，windows对runtime做了严格限定不能一起用，linux是可以链接不同的c++abi的，见 https://github.com/xmake-io/xmake-repo/blob/dev/packages/f/filament/xmake.lua 这里预编译用的 libc++ 但gcc通过同时链接libstdc++ 和 libc++的方式也可以用 |
Isn't reuse appropriate here? The runtime processing of Unix is completely different from that of Windows. Windows has strict restrictions on runtime and cannot be used together. Linux can link to different C++abi. See https://github.com/xmake-io/xmake-repo/ blob/dev/packages/f/filament/xmake.lua libc++ is used for precompilation here, but gcc can also be used by linking libstdc++ and libc++ at the same time. |
? libstdc++ 和 libc++ 同时链接？符号不冲突么？没见过这种用法。 是否一起使用不是用户自己配置的么，如果用户同时配置了多个 runtimes ，当前编译器不支持，直接提示或者报错就行了。 |
? libstdc++ and libc++ linked at the same time? Don't the symbols conflict? Never seen this usage. Isn’t it up to the user to configure whether they are used together? If the user configures multiple runtimes at the same time, the current compiler does not support it. Just prompt or report an error directly. |
只要接口没有C++就不冲突，实现里面可以一起用，两个的符号导出不同，用其中一个编译另外一个链接的时候会报错找不到符号这一点就可以证明。事实上 Open3D https://github.com/isl-org/Open3D 一直就这么干的 https://github.com/isl-org/Open3D/blob/v0.18.0/3rdparty/find_dependencies.cmake#L1363-L1376
vs_runtime可以保证全局只有一个，但unix的不能；这个时候add_requires(xxx)传递的runtime信息就有问题了，package使用哪一个runtime编译呢？以及像filament这种预编译的包，runtime只有一个，链接的时候必须也链接libc++，目前的方案是依赖一个fetch-only的libc++ library，改成runtime参数之后，是不是每个包都要根据runtime设置依赖到libstdc++/libc++？ 另外就是，当前vs_runtime各种设置都是使用ucrt的，MT/MD只是静态链接和动态链接的区别。unix也有静态链接和动态链接的问题，不光是c++abi，glibc/llvm-libc都可以静态链接/动态链接；而windows也可以通过/nodefaultlib 来控制链接ucrt和msvcrt。runtime如果用来控制链接的标准库，那windows上是否也要抽象ucrt/msvcrt的区别？unix是否需要分动态/静态？而且C++abi的实现并不只有libstdc++和libc++（虽说这俩是主流）， https://en.cppreference.com/w/cpp/compiler_support 这里列出了一些其他stl的实现。 我觉得可以runtime控制静态/动态链接标准库的问题，而到底链接哪一个，交给用户判断，自己add_requires("libc++")去引入比较好。这样现有的package也不用动，修改一下package.tools.xxx里面安装的flags就好了。不手动加flag，就使用编译器默认的runtime。 |
即使能一起用，同时一起配置就行了，这并不冲突
上层设置多个 ，但是过滤到 package 当前生效的 toolchain 后，runtimes 已经被继续过滤到仅仅当前 toolchain 的 runtimes 了，如果 package 当前是 msvc ，那么传递过来实际只有 MT/MD ，唯一值，如果 package 当前 toolchain 是 gcc/clang ，那么传递过来的只有，c++/stdc++ ，都是跟当前 toolchain 关联过滤的，没啥问题，你每个 package 当前总归有个实际使用的 toolchain。
如果这个包只能用 libc++ ，那还是现在的包配置不变，顶多 add_configs runtimes 设置为 readonly 固定到 libc++ 呗。没啥其他变动。
不对吧，MT/MD 不仅仅只是切静态动态，配置MD的同时，就是切了 msvcrt，配置 MT 就是切 ucrt ，并不是 /nodefaultlib 控制的，那个只是配置忽略默认的 libcmt 或者 msvcrt https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170
官方文档明确说了 MD 走 msvcrt ，MT 走 libcmt
所以这个现在已经走 runtimes MT/MD 处理掉了，没有其他额外的抽象
所以目前是做成
所以 set_runtimes 是扩展性的，不单纯可以设置 MT/MD 和 libc++/libstdc++ 。。我们还可以设置其他的，比如 低版本 ndk 的 stlport_static/stlport_shared 。。 也可以设置其他 toolchain 支持的 c++abi 库。。现在统一走 runtimes ，反而更具有扩展性了。而不是现在只能 vs_runtimes, ndk_cxxstl ，set_runtimes 各种特定工具链配置，单独处理，扩展性和统一性都不放便 |
|
另外，现在的不统一，对于后期 packages / target / toolchain 里面的 runtimes, c++abi 设置，还有 c++ modules 里面不同编译器的 c++abi 设置，还有对 conan/vcpkg内 c++_abi 的适配， 各种处理都需要特殊处理，很乱，没法统一处理 |
In addition, the current situation is not uniform, regarding the runtimes and c++abi settings in later packages/target/toolchain, as well as the c++abi settings of different compilers in c++ modules, and the c++_abi in conan/vcpkg Adaptation, all kinds of processing require special processing, it is very messy and cannot be processed uniformly |
|
Nice when it's merged, i will rebase my module PR to use it for libc++ handling |
|
初步搞好了，目前是完全兼容现有的 vs_runtime 使用的，理论上应该不会 break 任何东西，内部实现尽可能已经切到统一的 runtimes 了，外面的仓库包，目前还是可以使用 vs_runtime，等发版后，可以逐步迁移到 runtimes 上去。。 可以帮忙测试下，毕竟改动比较多，也可能会 break 些未知的东西，得多测测。#4477 对于 package 内部 runtimes 的使用，会根据当前 toolchain，约束到实际支持的 runtimes，也就是说，如果是 msvc ，那么 package:runtimes() 返回的还是 MT, MD 等单值的字符串，用法一样。。即使配置了 MT,c++_static 多值，也会仅仅生效 MT xmake update -s github:xmake-io/xmake#runtimes |
waruqi
requested review from
xq114,
SirLynix,
da-liii,
Arthapz and
star-hengxing
It has been initially completed. It is currently fully compatible with the existing vs_runtime. In theory, it should not break anything. The internal implementation has been cut to unified runtimes as much as possible. For external warehouse packages, vs_runtime can still be used. Wait for the release. After the version is released, you can gradually migrate to runtimes. . Can you help me test it? After all, there are a lot of changes, and some unknown things may break, so I need to test it more. #4477 The use of runtimes within the package will be constrained to the actual supported runtimes based on the current toolchain. That is to say, if it is msvc, then package:runtimes() will still return single-valued strings such as MT, MD, etc., and the usage is the same. . Even if MT, c++_static multi-value is configured, only MT will take effect. |
|
nothing break on my side |
|
Same, everything works great from package installation to compilation with MDd and MD runtimes. |
|
runtime现在似乎是存的一个字符串？但package需要的实际上是当前平台的runtime，比如runtime为"MT,c++_static"，而windows上add_requires的package计算hash/on_install的时候只需要MT，"MT,c++_static"和"stdc++_static,MT"不应该有任何区别。现在的实现可以做到吗？ |
现在的实现，传 "MT,c++_static"和"stdc++_static,MT" ，在 windows 上，最终从 |
hash 计算上，过于早期，目前还是带上 stdc++_static 的，这块确实还得想个办法处理下 |
现在处理过了，buildhash 前就会提前过滤 runtimes。可以再试试 |
|
tested on the latest dev, nothing break on my side too |
#4477