find_program 在 msys 上寻找脚本文件的逻辑过于严格

[q962]

Xmake 版本

2.7.1

操作系统版本和架构

MINGW64_NT-10.0-19044 looyatest 3.3.5-341.x86_64 2022-05-13 15:40 UTC x86_64 Msys

描述问题

使用 find_program(program_name) 寻找脚本文件时，最终会执行 sandbox_lib_detect_find_program._check

但是，该行的判断逻辑是否太过严格？
https://github.com/xmake-io/xmake/blob/v2.7.1/xmake/core/sandbox/modules/import/lib/detect/find_program.lua#L82-L82

只允许绝对路径（还必须是 windows 风格的绝对路径），和相对项目的路径。还会判断文件大小。意义是什么？

期待的结果

 elseif os.subhost() == "msys" then
     -- only a sh script on msys2? e.g. c:/msys64/usr/bin/7z
     -- we need use sh to wrap it, otherwise os.exec cannot run it
     program = "sh " .. program
     findname = program
 end

验证逻辑完全交给 shell 去处理

应该使用 sh -c "..." 所以还不能使用 os.runv

工程配置

No response

附加信息和错误日志

No response

[waruqi]

尽可能避免没必要的 sh wrap，也能提高检测和运行效率，否则不管跑任何编译还是啥，都是各种 sh 7z, sh gcc xxx 这种，先不说是否有副作用，看着就难受。。

[q962]

让它最后的可用方案。

是否可以通过管道拉起一个shell，避免重复执行shell？

[waruqi]

我就是想尽可能避免 不去拉起 shell 搞事，才这么干的。。明明可以直接跑的 ，非得跑到 shell 里，多了一层不说，还额外多了一层 pipe 的处理和 stdin/stdout 的转发，没必要。

[q962]

避免不了，也没必要避免。并不是所有的程序都是pe格式。例如 node，py，dart 之类的。
这是用户的选择，你可以提示使用 shell wrap 会降低运行效率。
’既然选择了 msys 那就是想要linux的体验，shell 执行缓慢，那应该向 msys或者shell项目提反馈。要么就忍受。

[waruqi]

避免不了，也没必要避免。并不是所有的程序都是pe格式。例如 node，py，dart 之类的。

无所谓，如果是 xmake 内部需要的工具，或者常用工具，有专门的 find_node.lua 去针对性改进查找，wrap 上 sh，或者 patch .cmd 什么的都可以。

这是用户的选择，你可以提示使用 shell wrap 会降低运行效率。

如果是用户自己想要 find_tool，直接用户自己 find_tool("sh node") 就完事了，而且用户自己也没必要用 find_tool，直接 os.exec("sh node") 运行就完事了。。

’既然选择了 msys 那就是想要linux的体验，shell 执行缓慢，那应该向 msys或者shell项目提反馈。要么就忍受。

忍来干嘛，反正现在的逻辑，够用了，内部也能对特定 tool 提供 find_xxx.lua 脚本来改进查找。