Why did you go to system? . .
Why did you go to system? . .
Got it, system defaults to true. . .
system::xxx 应该按照编译器探测才对，探测系统上编译器本来就能找到的包，不能加-isystem 之类flag，编译器自己找不到的包按不能用算。就像上面给的链接，对系统已有的路径加-isystem，那作用是去掉这个搜索路径，xmake不能这么加。
> cpp -v /dev/null -o /dev/null
Using built-in specs.
COLLECT_GCC=cpp
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -o /dev/null -mtune=generic -march=x86-64 -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -dumpbase null
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
要么用parse cpp输出替换xmake里hardcode的includedirs，要么直接生成一段cpp程序尝试编译一下是否通过（直接链接要用的库），不走xmake自己的文件系统查找程序了。这么做还有一个好处，用户现在可以通过cflags来控制system::xxx的查找，这样对于手动安装、没有pkgconfig/cmake文件的包，也不用在xmake文件里硬编码路径add_links引入了。
#include <library.includes>
https://github.com/xmake-io/xmake/blob/master/xmake/modules/package/manager/system/find_package.lua
对于在系统上安装了却不在编译器搜索路径里的包，我认为应该无视而不是强行链接它们，因为不在编译器搜索路径说明人为进行了隔离，要么是编译器版本不匹配，要么是不希望用到这些包而隔离的。
我记得默认走 pkg-config 就能找到 zlib 的
这里zlib换成pkg-config当然可以，但不解决根本问题，其他使用system::xxx 找到的包还是不能用
system::xxx should be detected according to the compiler. It detects packages that the compiler can already find on the system. Flags such as -isystem cannot be added. Packages that the compiler cannot find by itself cannot be used. Just like the link given above, adding -isystem to the existing path in the system will remove the search path, which xmake cannot add.
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
According to the output of cpp -v /dev/null -o /dev/null, you can find the appropriate includedirs and linkdirs. Find the required links and includes here.
> cpp -v /dev/null -o /dev/null
Using built-in specs.
COLLECT_GCC=cpp
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README. Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix =-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads= posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx- abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with -target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 -- with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4. 0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking =release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization= 2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -o /dev/null -mtune=generic -march=x86-64 - fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -dumpbase null
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/:/usr /lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/:/ usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr /lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../:/lib/: /usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
Either use the parse cpp output to replace the includedirs of the hardcode in xmake, or directly generate a cpp program and try to compile it to see if it passes (directly linking the library to be used), without using xmake's own file system search program. Another advantage of this is that users can now control the search for system::xxx through cflags. This way, for packages that are manually installed and do not have pkgconfig/cmake files, there is no need to introduce the hard-coded path add_links in the xmake file.
#include <library.includes>
https://github.com/xmake-io/xmake/blob/master/xmake/modules/package/manager/system/find_package.lua
For packages that are installed on the system but are not in the compiler search path, I think they should be ignored rather than forcibly linked, because not being in the compiler search path means artificial isolation, either the compiler version does not match, or it is not expected Isolated using these packages.
I remember that by default, you can find zlib by running pkg-config
It is of course possible to replace zlib with pkg-config here, but it does not solve the fundamental problem. Other packages found using system::xxx still cannot be used.
One of my user had this issue on Linux, because zlib was found on system (system::z):
n3g xmake require --fetch zlib
links = {
includedirs = {
"/usr/include"
linkdirs = {
"/usr/lib/x86_64-linux-gnu"
but adding -isystem /usr/include to the gcc commandline broke compilation:
f7d458e8a93b5a/include -o build/.objs/n3g/linux/x86_64/release/src/main.cpp.o src/main.cpp
In file included from /usr/include/c++/11/ext/string_conversions.h:41,
from /usr/include/c++/11/bits/basic_string.h:6608,
from /usr/include/c++/11/string:55,
from /usr/include/c++/11/bits/locale_classes.h:40,
from /usr/include/c++/11/bits/ios_base.h:41,
from /usr/include/c++/11/ios:42,
from /usr/include/c++/11/ostream:38,
from /usr/include/c++/11/iostream:39,
from src/main.cpp:1:
/usr/include/c++/11/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
I think include and linkdirs shouldn't be added except when cross-compiling, something already done for xcodedirs (in _find_package_from_xcodedirs):
if result then
-- we don't need to add linkdirs again if we are building target on the current platform (with -isysroot)
if config.plat() ~= opt.plat or config.arch() ~= opt.arch then
result.linkdirs = linkdirs
result.includedirs = includedirs
我的一个用户在 Linux 系统上遇到了这个问题，因为在系统 (system::z) 中找到了 zlib：
n3g xmake require --fetch zlib
links = {
includedirs = {
"/usr/include"
linkdirs = {
"/usr/lib/x86_64-linux-gnu"
但在 gcc 命令行中添加 -isystem /usr/include 会导致编译失败：
f7d458e8a93b5a/include -o build/.objs/n3g/linux/x86_64/release/src/main.cpp.o src/main.cpp
In file included from /usr/include/c++/11/ext/string_conversions.h:41,
from /usr/include/c++/11/bits/basic_string.h:6608,
from /usr/include/c++/11/string:55,
from /usr/include/c++/11/bits/locale_classes.h:40,
from /usr/include/c++/11/bits/ios_base.h:41,
from /usr/include/c++/11/ios:42,
from /usr/include/c++/11/ostream:38,
from /usr/include/c++/11/iostream:39,
from src/main.cpp:1:
/usr/include/c++/11/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
我认为，除非在交叉编译时，否则不应该添加 include 和 linkdirs，xcodedirs 已经这样做了（在 _find_package_from_xcodedirs 中）：
if result then
-- we don't need to add linkdirs again if we are building target on the current platform (with -isysroot)
if config.plat() ~= opt.plat or config.arch() ~= opt.arch then
result.linkdirs = linkdirs
result.includedirs = includedirs
按 cpp -v /dev/null -o /dev/null 的输出可以找到应有的includedirs 和 linkdirs ，在这里找需要的 link 和includes
macos 上的输出找不到 linkdirs
$ cpp -v /dev/null -o /dev/null
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin23.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx14.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=2 -target-sdk-version=14.0 -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 1015.6 -v -fcoverage-compilation-dir=/Users/ruki/projects/qiyi/harmony/iqiyi_harmony -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -fdebug-compilation-dir=/Users/ruki/projects/qiyi/harmony/iqiyi_harmony -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcommon -fcolor-diagnostics -traditional-cpp -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -mllvm -disable-aligned-alloc-awareness=1 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o - -x c /dev/null
clang -cc1 version 15.0.0 (clang-1500.0.40.1) default target x86_64-apple-darwin23.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 384 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin23.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang: warning: argument unused during compilation: '-traditional' [-Wunused-command-line-argument]
要么用parse cpp输出替换xmake里hardcode的includedirs，要么直接生成一段cpp程序尝试编译一下是否通过（直接链接要用的库），不走xmake自己的文件系统查找程序了。这么做还有一个好处，用户现在可以通过cflags来控制system::xxx的查找，这样对于手动安装、没有pkgconfig/cmake文件的包，也不用在xmake文件里硬编码路径add_links引入了。
可以尝试下
那这种呢 #1776 之前你提的搜索用户自定义路径，这么搞，编译器也能找到？
What about this one? #1776 You mentioned searching for user-defined paths before. Can the compiler also find it this way?
Yes, those variables are originally environment variables that the compiler will look for additionally.
#4600
试试，通过 check_cxsnippets 的方式探测，参数用法和它一致。configs 里面可以传 defines/cflags/links等等
如果尝试编译检测通过，configs 里面的所有配置，都会作为 find_package 结果返回。。
package:find_package("system::z", {includes = "zlib.h", configs = {defines = "TEST"}})
package:find_package("system::zlib", {includes = "zlib.h", configs = {links = "z"}})
另外，还可以传 funcs/snippets 参数，严格定制化检测
#4600
Try it and detect it through check_cxsnippets. The parameter usage is consistent with it. Defines/cflags/links, etc. can be passed in configs
If the attempted compilation test passes, all configurations in configs will be returned as find_package results. .
package:find_package("system::z", {includes = "zlib.h", configs = {defines = "TEST"}})In addition, you can also pass funcs/snippets parameters to strictly customize the detection.
The case was solved. Someone modified the zlib package, which resulted in the indirect use of the system library system::z:
You can use the xmake-requires.lock function. I just used it recently, see https://github.com/XmacsLabs/mogan/blob/branch-1.2/xmake-requires.lock
破案了，有人修改了 zlib 包，这里导致间接使用系统库 system::z ：
可以用一下xmake-requires.lock这个功能，我最近刚刚用上，see https://github.com/XmacsLabs/mogan/blob/branch-1.2/xmake-requires.lock
我之前用过，但是在我们的环境发现一些 bug。用户编译，不知道为什么，导致 xmake-requires.lock 文件被 xmake 修改掉，文件全乱了。我暂时没法用最小工程复现它。
The case was solved. Someone modified the zlib package, which resulted in the indirect use of the system library system::z:
You can use the xmake-requires.lock function. I have just used it recently, see https://github.com/XmacsLabs/mogan/blob/branch-1.2/xmake-requires.lock
I've used it before, but found some bugs in our environment. When compiled by the user, for some unknown reason, the xmake-requires.lock file was modified by xmake and the files were all messed up. I can't reproduce it with minimal project yet.
system::xxx 应该按照编译器探测才对，探测系统上编译器本来就能找到的包，不能加-isystem 之类flag，编译器自己找不到的包按不能用算。就像上面给的链接，对系统已有的路径加-isystem，那作用是去掉这个搜索路径，xmake不能这么加。
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
按 cpp -v /dev/null -o /dev/null 的输出可以找到应有的includedirs 和 linkdirs ，在这里找需要的 link 和includes
> cpp -v /dev/null -o /dev/null
Using built-in specs.
COLLECT_GCC=cpp
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -o /dev/null -mtune=generic -march=x86-64 -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -dumpbase null
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
要么用parse cpp输出替换xmake里hardcode的includedirs，要么直接生成一段cpp程序尝试编译一下是否通过（直接链接要用的库），不走xmake自己的文件系统查找程序了。这么做还有一个好处，用户现在可以通过cflags来控制system::xxx的查找，这样对于手动安装、没有pkgconfig/cmake文件的包，也不用在xmake文件里硬编码路径add_links引入了。
#include <library.includes>
https://github.com/xmake-io/xmake/blob/master/xmake/modules/package/manager/system/find_package.lua
对于在系统上安装了却不在编译器搜索路径里的包，我认为应该无视而不是强行链接它们，因为不在编译器搜索路径说明人为进行了隔离，要么是编译器版本不匹配，要么是不希望用到这些包而隔离的。
我记得默认走 pkg-config 就能找到 zlib 的
这里zlib换成pkg-config当然可以，但不解决根本问题，其他使用system::xxx 找到的包还是不能用
现在 system/find_package 里面去调用编译器检测，会有个问题，find_package 是在 package:fetch 阶段就会被执行。。这个时候使用 package toolchain，得先 check package toolchain
目前这个 check 仅仅是在 install 阶段才会去做，所以会导致一些 toolchain 在 fetch 阶段检测失败被缓存，后期安装时候，也会失败。。例如 link.exe 前期检测失败，干扰了后期 clang-cl/link 安装 #4859
但如果将 check package toolchain 提前到 fetch 阶段做，有些包是 toolchain 包，有依赖关系，都还没安装上，会检测不到，也不行。
system::xxx should be detected according to the compiler. It detects packages that the compiler can already find on the system. Flags such as -isystem cannot be added. Packages that the compiler cannot find by itself cannot be used. Just like the link given above, adding -isystem to the existing path in the system will remove the search path, which xmake cannot add.
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Press the output of cpp -v /dev/null -o /dev/null to find the appropriate includedirs and linkdirs. Find the required links and includes here
> cpp -v /dev/null -o /dev/null
Using built-in specs.
COLLECT_GCC=cpp
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README .Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program- suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads =posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx -abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release -- with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 - -with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4 .0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable- checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization =2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -o /dev/null -mtune=generic -march=x86-64 -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -dumpbase null
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/:/ usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/: /usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/ usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/11/../../../:/lib/ :/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
Either use parse cpp output to replace the includedirs of hardcode in xmake, or ** directly generate a cpp program and try to compile it ** to see if it passes (directly link to the library to be used), without using xmake's own file system search program. Another advantage of this is that users can now control the search for system::xxx through cflags. This way, for packages that are manually installed and do not have pkgconfig/cmake files, there is no need to introduce the hard-coded path add_links in the xmake file.
#include <library.includes>
https://github.com/xmake-io/xmake/blob/master/xmake/modules/package/manager/system/find_package.lua
For packages that are installed on the system but are not in the compiler search path, I think they should be ignored rather than forcibly linked. Because they are not in the compiler search path, it means artificial isolation, either the compiler version does not match, or it is not I hope to use these packages and isolate them.
I remember that by default, you can find zlib by running pkg-config.
It is of course possible to replace zlib with pkg-config here, but it does not solve the fundamental problem. Other packages found using system::xxx still cannot be used.
Now there will be a problem when calling compiler detection in system/find_package. find_package will be executed during the package:fetch stage. . To use package toolchain at this time, you must first check package toolchain
Currently, this check is only done during the install phase, so some toolchains may fail to be detected during the fetch phase and be cached, and may also fail during later installations. . For example, the early detection of link.exe failed, which interfered with the later installation of clang-cl/link #4859
However, if you move the check package toolchain to the fetch stage in advance, some packages are toolchain packages and have dependencies that have not been installed yet, so they will not be detected and will not work.
现在 system/find_package 里面去调用编译器检测，会有个问题，find_package 是在 package:fetch 阶段就会被执行。。这个时候使用 package toolchain，得先 check package toolchain
目前这个 check 仅仅是在 install 阶段才会去做，所以会导致一些 toolchain 在 fetch 阶段检测失败被缓存，后期安装时候，也会失败。。例如 link.exe 前期检测失败，干扰了后期 clang-cl/link 安装 #4859
但如果将 check package toolchain 提前到 fetch 阶段做，有些包是 toolchain 包，有依赖关系，都还没安装上，会检测不到，也不行。
理论上一个包on_fetch就是应该带toolchain信息的，不同的toolchain能用的包都不一样，除了本身就是toolchain类型的包。能不能在添加package的时候单独处理toolchain？先安装/加载toolchain类型，完成之后再绑定toolchain的环境变量去安装/加载别的包？
（其实对于remote toolchain我更倾向于把toolchain单独写到本地env.lua里而不是写到xmake.lua里，用xrepo env shell加载之后再跑xmake。toolchain本来就应该是各个机器有自己的toolchain版本，xmake.lua不应该完全定死一个toolchain）
现在 system/find_package 里面去调用编译器检测，会有个问题，find_package 是在 package:fetch 阶段就会被执行。。这个时候使用 package toolchain，得先 check package toolchain
目前这个 check 仅仅是在 install 阶段才会去做，所以会导致一些 toolchain 在 fetch 阶段检测失败被缓存，后期安装时候，也会失败。。例如 link.exe 前期检测失败，干扰了后期 clang-cl/link 安装 #4859
但如果将 check package toolchain 提前到 fetch 阶段做，有些包是 toolchain 包，有依赖关系，都还没安装上，会检测不到，也不行。
理论上一个包on_fetch就是应该带toolchain信息的，不同的toolchain能用的包都不一样，除了本身就是toolchain类型的包。能不能在添加package的时候单独处理toolchain？先安装/加载toolchain类型，完成之后再绑定toolchain的环境变量去安装/加载别的包？
我知道，但是现在不太好实现 fetch 阶段使用 toolchain。。关键是要同时支持 其他包依赖 toolchain 包的情况。。
比如设置了 add_requires("llvm") 和 set_toolchain("@llvm") ，那么其他 add_requires 都要依赖使用 llvm 包，如果在所有包 加载阶段，先初始化 toolchain，那么这些包的 llvm toolchain 依赖的 llvm package 都还没安装，根本没法初始化。。
如果先初始化 package 和 fetch ，就会遇到当前 fetch 阶段调用 toolchain find_package 失败的问题。
除非是搞成，llvm 这些 toolchain 包，先全部安装好，之后再安装其他包，这个逻辑就更复杂了。
不过目前我稍微做了折中，暂时应该没问题了。
（其实对于remote toolchain我更倾向于把toolchain单独写到本地env.lua里而不是写到xmake.lua里，用xrepo env shell加载之后再跑xmake。toolchain本来就应该是各个机器有自己的toolchain版本，xmake.lua不应该完全定死一个toolchain）
走 xrepo env shell 还是走 xmake.lua ，都是用户自己的需求决定的事情，我们决定不了，xmake 只能同时把这两种方式都支持了，用户怎么用是用户的事情。。
另外，都在 xmake.lua 对于一些新手，可以实现一键 xmake 编译，自动拉取 toolchain 和使用，可以有效降低使用门槛，避免趟坑。。不可能每个工程都去 readme 里面写一堆，如果对不同 toolchain ，去配置 xrepo env 加载编译，用户估计看到这么复杂，直接吓跑了。
Now there will be a problem when calling compiler detection in system/find_package. find_package will be executed in the package:fetch stage. . To use package toolchain at this time, you must first check package toolchain
At present, this check is only done during the install phase, so some toolchains will fail to be detected during the fetch phase and be cached. They will also fail during later installations. . For example, the early detection of link.exe failed, which interfered with the later installation of clang-cl/link #4859
But if you move the check package toolchain to the fetch stage in advance, some packages are toolchain packages and have dependencies that have not been installed yet, so they will not be detected and it will not work.
Theoretically, a package on_fetch should carry toolchain information. Different toolchains can use different packages, except for packages that are toolchain types themselves. Can the toolchain be processed separately when adding a package? Install/load the toolchain type first, and then bind the toolchain environment variables to install/load other packages?
I know, but it's not easy to implement the fetch phase using toolchain now. . The key is to also support the situation where other packages depend on the toolchain package. .
For example, if add_requires("llvm") and set_toolchain("@llvm") are set, then other add_requires will depend on the llvm package. If the toolchain is initialized first during all package loading stages, then the llvm toolchain dependencies of these packages will The llvm package has not been installed yet and cannot be initialized at all. .
If you initialize package and fetch first, you will encounter the problem of failure to call toolchain find_package in the current fetch stage.
Unless it is done, all the llvm toolchain packages must be installed first, and then other packages can be installed. This logic will be more complicated.
But now I've made a slight compromise and it should be fine for the time being.
(In fact, for the remote toolchain, I prefer to write the toolchain separately into the local env.lua instead of writing it into xmake.lua, load it with xrepo env shell and then run xmake. The toolchain should originally be that each machine has its own toolchain Version, xmake.lua should not completely determine a toolchain)
Whether to use xrepo env shell or xmake.lua is decided by the user's own needs. We cannot decide. xmake can only support both methods at the same time. How to use it is up to the user. .
In addition, it is all in xmake.lua. For some novices, they can realize one-click xmake compilation, automatically pull the toolchain and use it, which can effectively lower the threshold of use and avoid pitfalls. . It is impossible to write a lot of information in the readme for every project. If you configure xrepo env to load and compile different toolchains, users will probably be scared away when they see such complexity.
