headerpaths的 stl 搜索目录探测存在错误
Xmake 版本
xmake v2.7.9+dev.d51436e32
操作系统版本和架构
Windows 11 22H2
描述问题
import <immintrin.h>;
xmake时产生错误error: find <immintrin.h> not found!
原因是headerpaths探测出来的目录是"D:\Tools\gcc\include\c++\14.0.0"
但实际上gcc的包含路径有这么多
D:\Tools\gcc\include\c++\14.0.0
D:\Tools\gcc\include\c++\14.0.0\x86_64-w64-mingw32
D:\Tools\gcc\include\c++\14.0.0\backward
D:\Tools\gcc\lib\gcc\x86_64-w64-mingw32\14.0.0\include
D:\Tools\gcc\include
而偏偏immintrin.h就在D:\Tools\gcc\lib\gcc\x86_64-w64-mingw32\14.0.0\include里
并且在探测clang的时候忽略了--target选项的作用,若运行clang++ a.cpp -v --target=x86_64-w64-windows-msvc
则输出的include目录是
D:/Tools/clang/lib/clang/17/include
D:\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include
D:\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\ATLMFC\include
D:\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\VS\include
D:\Windows Kits\10\include\10.0.22000.0\ucrt
D:\Windows Kits\10\include\10.0.22000.0\um
D:\Windows Kits\10\include\10.0.22000.0\shared
D:\Windows Kits\10\include\10.0.22000.0\winrt
D:\Windows Kits\10\include\10.0.22000.0\cppwinrt
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um
然而探测出来的目录是"D:\Tools\gcc\include\c++\14.0.0"
期待的结果
至少应该包含所有重要的包含目录,包括c++标准库(D:\Tools\gcc\include\c++\14.0.0),c标准库(D:\Tools\gcc\include),sdk头文件(D:\Tools\gcc\include),平台相关头文件(对于gcc是D:\Tools\gcc\lib\gcc\x86_64-w64-mingw32\14.0.0\include对于clang是 D:/Tools/clang/lib/clang/17/include)。这可以让编译器用全部的全局选项编译一个空白的cpp文件并探测#include <...> search starts here:语句来得到所有可能的目录
工程配置
使用xmake f --toolchain=clang或xmake f --toolchain=gcc构建
附加信息和错误日志
xmake build -vD Test
[ 0%]: generating.module.deps MyDetail\MyMemory.ixx
gcc -E -x c++ -m64 -g -Wall -Wextra -std=c++23 -DUNICODE -D_UNICODE -D_DLL -DDEBUG -D_DEBUG -DMyStdCStandardSupport -fexceptions -march=native -D_GLIBCXX_USE_CXX11_ABI=0 MyDetail\MyMemory.ixx -o build\.gens\MyDetail\cross\x64\Debug\rules\modules\cache\c6251745\MyMemory.ixx.i
error: @programdir\core\main.lua:300: @programdir\actions\build\main.lua:206: @programdir\rules\c++\modules\modules_support\common.lua:490: find <crtdbg.h> not found!
stack traceback:
[C]: in function 'error'
[@programdir\core\base\os.lua:913]: in function 'raiselevel'
[@programdir\core\sandbox\modules\utils.lua:149]: in function 'assert'
[@programdir\rules\c++\modules\modules_support\common.lua:490]: in function 'find_angle_header_file'
[@programdir\rules\c++\modules\modules_support\common.lua:569]: in function 'fallback_generate_dependencies'
[@programdir\rules\c++\modules\modules_support\gcc.lua:206]: in function 'callback'
[@programdir\modules\core\project\depend.lua:193]: in function 'on_changed'
[@programdir\rules\c++\modules\modules_support\gcc.lua:187]: in function 'generate_dependencies'
[@programdir\rules\c++\modules\modules_support\common.lua:603]: in function 'get_module_dependencies'
[@programdir\rules\c++\modules\xmake.lua:71]: in function 'script'
[@programdir\actions\build\kinds\object.lua:101]: in function '_add_batchjobs_for_rule'
[@programdir\actions\build\kinds\object.lua:209]: in function '_add_batchjobs_for_group'
[@programdir\actions\build\kinds\object.lua:246]:
[@programdir\actions\build\build.lua:69]: in function '_add_batchjobs_builtin'
[@programdir\actions\build\build.lua:82]: in function '_add_batchjobs'
[@programdir\actions\build\build.lua:150]: in function '_add_batchjobs_for_target'
[@programdir\actions\build\build.lua:193]: in function '_add_batchjobs_for_target_and_deps'
[@programdir\actions\build\build.lua:203]: in function '_add_batchjobs_for_target_and_deps'
[@programdir\actions\build\build.lua:203]: in function '_add_batchjobs_for_target_and_deps'
[@programdir\actions\build\build.lua:241]: in function 'get_batchjobs'
[@programdir\actions\build\build.lua:256]:
[@programdir\actions\build\main.lua:109]: in function '_do_build'
[@programdir\actions\build\main.lua:180]:
stack traceback:
[C]: in function 'error'
@programdir\core\base\os.lua:913: in function 'os.raiselevel'
(...tail calls...)
@programdir\core\main.lua:300: in upvalue 'cotask'
@programdir\core\base\scheduler.lua:404: in function <@programdir\core\base\scheduler.lua:397>
Bot detected the issue body's language is not English, translate it automatically.
Title: headerpaths
而偏偏immintrin.h就在D:\Tools\gcc\lib\gcc\x86_64-w64-mingw32\14.0.0\include里 并且在探测clang的时候忽略了--target选项的作用,若运行clang++ a.cpp -v --target=x86_64-w64-windows-msvc 则输出的include目录是
这个目前加不了,原本 fallback 方案就是不精准,不完全可靠的。
至少应该包含所有重要的包含目录
全加上,也有可能导致其他一些头文件冲突
如果要想稳定可靠,你只有等 gcc 原生支持 p1689 导出生成模块依赖图,就不用走这种方式 fallback 生成了。。
另外,windows 上,mingw 的 gcc 对 modules 支持还有很多其他问题,比如 mapper 的支持也有坑,不确定非 mingw 的 gcc 是不是也是如此。
建议你在 windows 最好还是老老实实用 msvc ,目前支持相对完善些。
Bot detected the issue body's language is not English, translate it automatically.
But immintrin.h is in D:\Tools\gcc\lib\gcc\x86_64-w64-mingw32\14.0.0\include And when detecting clang, the --target option is ignored. If you run clang++ a.cpp -v --target=x86_64-w64-windows-msvc Then the output include directory is
This cannot be added at present, the original fallback solution is imprecise and not completely reliable.
At least all important include directories should be included
All added, it may also cause some other header file conflicts
If you want to be stable and reliable, you have to wait for gcc to natively support p1689 export to generate module dependency graphs, and you don’t need to use this method to generate fallbacks. .
Bot detected the issue body's language is not English, translate it automatically.
In addition, on windows, mingw gcc has many other problems in supporting modules. For example, the support of mapper also has pitfalls. I am not sure if the same is true for non-mingw gcc.
如果你这也是 mingw gcc,至少我之前知道的情况,还是完全不可用状态的。。gcc 有 bug 。。就算你全加上这些 路径,也不可能编译过。
https://github.com/msys2/MINGW-packages/issues/12797
尝试了一下,目前给clang加上完整的路径是可以正常编译的
function find_angle_header_file(target, file)
--[[ local headerpaths = modules_support(target).toolchain_includedirs(target) ]]
local headerpaths = {"D:/Tools/gcc/include/c++/14.0.0",
"D:/Tools/gcc/include/c++/14.0.0/x86_64-w64-mingw32",
"D:/Tools/gcc/include/c++/14.0.0/backward",
"D:/Tools/gcc/lib/gcc/x86_64-w64-mingw32/14.0.0/include",
"D:/Tools/gcc/include"}
全加上,也有可能导致其他一些头文件冲突
这应该不会,因为编译器本身也是从这些路径中寻找头文件的
Bot detected the issue body's language is not English, translate it automatically.
I tried it, and now adding a complete path to clang can compile normally
function find_angle_header_file(target, file)
--[[local headerpaths = modules_support(target).toolchain_includedirs(target)]]
local headerpaths = {"D:/Tools/gcc/include/c++/14.0.0",
"D:/Tools/gcc/include/c++/14.0.0/x86_64-w64-mingw32",
"D:/Tools/gcc/include/c++/14.0.0/backward",
"D:/Tools/gcc/lib/gcc/x86_64-w64-mingw32/14.0.0/include",
"D:/Tools/gcc/include"}
All added, may also cause some other header file conflicts
This should not be the case, because the compiler itself looks for header files from these paths
这应该不会,因为编译器本身也是从这些路径中寻找头文件的
但是显式加,不能乱加的,会有各种问题。。还有加个顺序不对,也会有问题。
就比如这个 mingw gcc 显式加了 sysroot 或者 -I/usr/include ,就会 break 很多东西,https://github.com/msys2/MINGW-packages/issues/10761
到现在还没完全很好解决
Bot detected the issue body's language is not English, translate it automatically.
This should not be the case, because the compiler itself looks for header files from these paths
However, if you add it explicitly, you cannot add it randomly, and there will be various problems. . Also, if the order is wrong, there will be problems.
For example, if this mingw gcc explicitly adds sysroot or -I/usr/include, it will break many things, https://github.com/msys2/MINGW-packages/issues/10761
It hasn't been fully resolved until now.