本地包的相关路径应该具有更高的优先级

[q962]

我安装了本地包，结果还是链接了系统的文件

[q962]

我想使用 xmake f --linkdirs 先跳过这个错误。

结果没有改变，对比前后，路径的顺序没有改变

[star-hengxing]

https://xmake.io/#/package/remote_package?id=disable-system-library

[star-hengxing]

你确定在 add requires 都设置 system = false 了么

[q962]

我只为我需要的库设置了 system = false。
是的，我尝试。
和我执行 xmake q -y --extra={system=false} 命令后的编译命令是一致的

[q962]

...objs
-m64  \
-LD:/msys64/mingw64/lib  \
-LD:/msys64/mingw64/lib/../lib  \
-LC:/Users/user/AppData/Roaming/.xmake/packages/l/lua/v5.4.7/1faf1df8f0dc4f9aaa2007626bb208eb/lib  \
-LD:/msys64/mingw64/bin/../lib  \
...

[star-hengxing]

已经用系统包管理安装了 libpng，无法复现。

add_requires("libpng", {system = false})

$ mingw
$ xmake f -c -v -p mingw
checking for architecture ... x86_64
checking for mingw directory ... C:/Users/star/scoop/apps/msys2/2024-07-27/mingw64
checking for unzip ... no
checking for 7z ... ok
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
git rev-parse HEAD
checking for xmake::zlib ... no
checking for pacman ... ok
checking for pkg-config ... no
checking for pkgconf ... no
checking for cygpath ... ok
checking for pacman::zlib ... zlib 1.3.1
checking for xmake::libpng ... no
note: install or modify (m) these packages (pass -y to skip confirm)?
in xmake-repo:
  -> libpng v1.6.43
please input: y (y/n/m)

system = true

$ xmake f -c -v -p mingw
checking for architecture ... x86_64
checking for mingw directory ... C:/Users/star/scoop/apps/msys2/2024-07-27/mingw64
checking for unzip ... no
checking for 7z ... ok
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
git rev-parse HEAD
checking for xmake::zlib ... no
checking for pacman ... ok
checking for pkg-config ... no
checking for pkgconf ... no
checking for cygpath ... ok
checking for pacman::zlib ... zlib 1.3.1
checking for xmake::libpng ... no
checking for pacman::libpng ... libpng 1.6.43

[q962]

你注意看我的上面发的编译命令。那是 xmake 的编译命令
很明显的，在本地包的lib路径之前有系统包路径。

[star-hengxing]

才想起以前提过类似的问题 #5066
需要改进 xmake 对系统包的查找才行，或者不混用系统包和 xmake 包

[q962]

参数爆炸，现在的参数长度已经够离谱了。

在Windows上，使用 meson 编译 gtk
meson 会生成 ninja，ninja 直接无法运行，参数爆炸
里面全是绝对路径，就离谱。

使用绝对路径是很容的绝对问题。但如果文件很多呢？参数得有多长？
不同的系统对参数的个数是有限制的吧
windows 是 8191
linux 应该没有这个问题

[q962]

我目前的参数已经达到了 5399，差不多 30个文件吧。

当让这个可以进行优化，将多个 obj 进行合并。这个工作由 xmake 做？

[star-hengxing]

参数太长，自然会优化成用文件传递。这个机制早就有了。
不过还会有 Windows 长路径限制的问题，平时很少出现，暂时无解、

[waruqi]

我目前的参数已经达到了 5399，差不多 30个文件吧。

当让这个可以进行优化，将多个 obj 进行合并。这个工作由 xmake 做？

目前原本就是自动处理了这个问题，否则你参数超过 1024 基本就已经跪了。

[waruqi]

不过还会有 Windows 长路径限制的问题，平时很少出现，暂时无解、

走 win 的 xmake 安装包，安装时候，就会默认帮用户修改注册表，开启长路径绕过的限制。当然用户也可以选择不开。

[waruqi]

这主要是由于 add_packages 即使按顺序追加包 linkdirs links 。。但是其中某个包如果用了 系统库，通过 pkg-config 或者其他系统库查找方式，获取带入了 -LD:/msys64/mingw64/lib 等系统根搜索路径后，穿插在 link flags 中间导致搜索顺序被干扰

即使 add_requires 后面的非系统包，xmake 也确实用了 自己安装的版本，-Lxx 到了自己的安装路径，但是被前面某个系统包引入的 -LD:/msys64/mingw64/lib 干扰了，链接器就会找错库位置。

这种只能说 xmake 本身的搜索行为并没问题，仅仅是包用了 -L/-l 链接库的一个副作用。。除非是所有的包改成 /xxxx/xxx.lib 完整库文件链接，才能完全规避这个问题。。

也就是通过上面说的 linkpath 方式，让 add_packages 完全走全路径链接，避免被搜索路径干扰。

[waruqi]

修改 xmake 文件就不是一个很好的选择。
所以需要提供一个方式来影响 xmake 的逻辑。

不是上面说了，有全局 policy 可以切 package.install_only 么。。policy 不都可以 xmake f --policies= 配置么

[q962]

不需要全部的包都走远程啊。
只有一个包有问题为什么要导致全部包重新编译呢

[waruqi]

那就单独那个包配置 linkpath 。。或者单独那个包 配置 system = false 。。但是命令行参数，不可能单独对某个包。。只能全局改。。

[q962]

所以我才会提出那种写法，手写全部的配置的 getenv，以应对可能的错误。
但是那样太繁琐了，也可以 on_load 里来处理这些环境变量。
所以我的建议是
改善 xmake q 命令，将 extra 的结果保存起来。
限制就是，如果在项目目录执行，并且该项目依赖这个包。

要不就 xmake 处理这些环境变量。例如 XMAKE_REQUIRE_xxx_system=1

[waruqi]

不考虑。太繁琐，要么你自定义个 option 去控制