add_requires支持代理

[playgithub]

刚需啊，github下载release太慢了，10KB/s都困难，libcurl加个参数，体验可以好很多
如：
add_requires("boost", {configs={proxy=sock5h://localhshot:1234})

[OpportunityLiu]

直接export HTTPS_PROXY=sock5h://localhshot:1234 不能用吗？

[OpportunityLiu]

你们这都是什么代理软件啊，连环境变量都不设的吗

[playgithub]

SSR

add_requires参数有几个优点：

1. 不会影响全局，设置环境变量会影响全局
2. 通过环境变量设置代理不仅影响全局，而且开启关闭切换相对麻烦，没有必要
3. 可以指定哪些包需要通过代理

[waruqi]

代理的详细配置可以放到 xmake config/global里面去配置

add_requires只需要指定是否开启代理

add_requires("boost", {proxy = true})

这个可以做，不过现在忙其他的，等排期吧，时间允许就下个版本，来不及的就只能再过个版本了

你先自己手动配置代理好了，自己通过域名白名单 也能控制哪些走代理

[OpportunityLiu]

环境变量影响全局是啥理论啊。。。

[playgithub]

环境变量不仅仅影响xmake

[waruqi]

curl和git的代理不是可以全局文件配置的么

[playgithub]

可以的，不如集成到xmake好，除了上面说的优点，还封装了git和curl，使用xmake不需要关心依赖git或curl

[OpportunityLiu]

所有工具不都认这玩意的吗
起码curl和git是的

[OpportunityLiu]

环境变量不仅仅影响xmake

还能影响到啥啊？ xmake里有请求的不就git和curl了

[playgithub]

举个例子：要单独使用使用git/curl（也就是和xmake无关）但不想使用代理，如果通过环境变量（http_proxy）/.curlrc/.gitconfig设置代理了代理，切换麻烦

[OpportunityLiu]

只给xmake设这个环境变量不就行了。。。

[playgithub]

总之，这样的接口不够好。
告诉xmake哪些包需要代理以及代理地址，这样接口更好。

[OpportunityLiu]

感觉不太对，这玩意做出来不是面临和yarn.lock (v1) 和 package-lock.json 一样的问题？换个编译环境直接爆炸，尤其是上 CI 的时候。

说到底，代理这个事情，基本上是和机器绑定的，即使要与xmake关联，也是放在 ~/.xmakerc 更合适吧

[OpportunityLiu]

add_requires 既然是声明式的，那就不应该去关心包从哪里来，怎么来的问题

倒是可以提供一个 package_resolver 的 API，通过在 ~/.xmakerc 进行配置，拦截获取包的请求，通过本地包源/镜像/代理下载提供内容

[playgithub]

接口只要代理地址以及哪些包需要代理就可以了。
实现可能要考虑多一些，但肯定可以实现的。

[waruqi]

全局的代理设置我加上了，对wget, curl和git都会生效，配置方式参考curl的用法就行了。

$ xmake g --help
    -x PROXY, --proxy=PROXY                                  Use proxy on given port. [PROTOCOL://]HOST[:PORT]
                                                                 e.g.
                                                                 - xmake g --proxy='http://host:port'
                                                                 - xmake g --proxy='https://host:port'
                                                                 - xmake g --proxy='socks5://host:port'

至于每个包的url过滤规则设置，等后面有时间，我需要先完善下 ~/.xmakerc.lua 才会加上支持，等后面看排期吧。。现在可以先全局切下凑活着用用。。

目前仅在toolchain分支生效

[waruqi]

xmakerc.lua配置里面我懒得整了，直接xmake global里面搞搞好了。。我加了个配置参数：

--proxy_hosts=PROXY_HOSTS                            Only enable proxy for the given hosts list, it will enable all if be unset,
                                                     and we can pass match pattern to list:
                                                         e.g.
                                                         - xmake g --proxy_hosts='github.com,gitlab.*,*.xmake.io'

用来设置代理host名单，如果没设置这个，启用了--proxy参数，那就是全局代理

如果设置了hosts列表，那么之后这个列表里面匹配的host才走代理。。

--proxy_host支持多个hosts设置，逗号分隔，并且支持基础的模式匹配 *.github.com， 以及其他lua模式匹配规则也支持

[OpportunityLiu]

这里又变成逗号分隔了？

[waruqi]

这里又变成逗号分隔了？

host又不是路径，一会win ; 一会 linux : 好乱的，而且: 也跟 host:port 冲突，虽然这里只过滤 host ，不过说不准以后还要过滤：http://xxx, https://xxx 这种的了，继续细分，这就跟:又冲突了

[OpportunityLiu]

可是之前那个 modes, archs也不是路径啊。。。。当时怎么想的

[waruqi]

可是之前那个 modes, archs也不是路径啊。。。。当时怎么想的

忘记了，原本当初我就是逗号分隔来着的，后来你给改成了 path sep，具体啥原因我也忘了。。反正想着跟其他的 带路径的 分隔统一下 也无所谓。。

不过这里 说不准之后会跟 : 冲突，还不如 , 兼容性好些。

[OpportunityLiu]

反正我记得讨论了一下你也没啥意见就改了。。不过应该还是兼容逗号的

[waruqi]

反正我记得讨论了一下你也没啥意见就改了。。不过应该还是兼容逗号的

是的，反正逗号也兼容的，所以也无所谓了。。其实我个人还是觉得 只有路径值列表 采用 sep 分隔，其他值还是能用逗号 统一各端会通用些。。

不然如果用户写脚本去wrap一些xmake调用传参，还得要求用户分win/unix去特殊处理 也很蛋疼。。

[playgithub]

这样xmake.lua只负责项目相关配置，很UNIX
本来想shadowsocks PAC模式倒很方便，不过依赖shadowsocks了

--proxy_hosts=PROXY_HOSTS，全局的怕太长，修改也比较麻烦，局部的每次写很麻烦。
如果不要--proxy_hosts=PROXY_HOSTS，要么全部代理要么全部不代理，最后是不是真正代理由代理软件决定，怎么样？

[waruqi]

先就这样吧 我懒得改了 反正xmake编译也不会拉太多包 长不了哪去 大部分host也都是github 再长就直接全局吧 让代理软件自己配置也可以

[playgithub]

--proxy_hosts默认是空还是*?

[playgithub]

考虑了一下，免费代理都不支持代理规则，xmake有hash检查，就算用免费代理也基本安全。现在这样不错。

[waruqi]

--proxy_hosts默认是空还是*?

默认不设置，就是全局生效

[waruqi]

        --proxy_pac=PROXY_PAC                                Set the auto proxy configuration file. (default: pac.lua)
                                                                 e.g.
                                                                 - xmake g --proxy_pac=pac.lua (in /Users/ruki/.xmake or absolute path)
                                                                 - function main(url, host)
                                                                       if host == 'github.com' then
                                                                            return true
                                                                       end
                                                                   end

我加了个proxy_pac参数，来设置pac自动代理规则

如果有proxy_hosts优先走这个，没有的话可以走pac。。

默认路径：~/.xmake/pac.lua 如果--proxy被设置，并且这个文件存在，就会自动走pac，如果不存在，也没hosts，那就全局生效

也可以手动指定pac全路径，xmake g --proxy_pac=/xxxx/xxxxx_pac.lua

配置规则描述：

function main(url, host)
    if host:find("bintray.com") then
        return true
    end
end

lua的，如果返回true，就是走代理，不返回或者返回false，就是不走代理。

[playgithub]

也是为了xmake更好，有什么想法我就直接说了

如果有proxy_hosts优先走这个，没有的话可以走pac
默认路径：~/.xmake/pac.lua 如果--proxy被设置，并且这个文件存在，就会自动走pac，如果不存在，也没hosts，那就全局生效
也可以手动指定pac全路径，xmake g --proxy_pac=/xxxx/xxxxx_pac.lua

觉得难记，对用户不够友好

这样怎么样

--proxy = "socks5://127.0.0.1:1080"
--proxy_rule = "path/to/proxy_rule.txt"

proxy_rule.txt可以用正则表达式一行一个，用正则表达式好处是普及、功能强、没有外部依赖

[waruqi]

proxy_hosts支持lua模式匹配，已足够使用，正则暂时不考虑支持，需要额外引入依赖库

目前就先这样了 暂时不考虑再改了

[playgithub]

好吧

---

PS:

1. lua支持正则很容易吧
2. proxy_hosts和proxy_pac两个，还有优先级关系，对用户不太友好

[waruqi]

lua支持正则很容易吧

不容易，得移植c库，还要封装上层lua接口，另外lua本身就有模式匹配，有多了个正则匹配，返回会给用户误导，哪些模块和场景走了lua模式匹配，哪些又得用正则的，目前add_files等大部分接口都是lua匹配，已经完全够用

另外lua的设计原本初衷就是简单、轻量，设计lua模式匹配就是为了保证轻量的同时，又能满足80%场景的匹配需求。

接入正则，就得一直pcre/pcre2等库进来，xmake也会变大不少，仅仅为了那1%的使用场景，去整个库进来，得不偿失，完全没必要

另外，目前这么多用下来， 个人觉得lua的模式匹配已经完全足够满足日常的匹配需求，如果真有些复杂的匹配做不到的场景，稍微写几行lua脚本也能处理

而xmake设计初衷之一，也要保证程序尽量精简、少依赖，不能因为功能越加越多，随便一个需求，就引入个库进来，一会正则库，一会7z库，回头不知道又要加什么库进来，这么搞法迟早得完。

proxy_hosts和proxy_pac两个，还有优先级关系，对用户不太友好

--help有说明，另外在不友好，就两个选择，研究个几分钟就会了，回头文档也会说明，除非用户不看文档和help，那我管不了。连文档都不看的人，不友好就不友好了。

[playgithub]

lua支持正则很容易吧

不容易，得移植c库，还要封装上层lua接口，另外lua本身就有模式匹配，有多了个正则匹配，返回会给用户误导，哪些模块和场景走了lua模式匹配，哪些又得用正则的，目前add_files等大部分接口都是lua匹配，已经完全够用

另外lua的设计原本初衷就是简单、轻量，设计lua模式匹配就是为了保证轻量的同时，又能满足80%场景的匹配需求。

接入正则，就得一直pcre/pcre2等库进来，xmake也会变大不少，仅仅为了那1%的使用场景，去整个库进来，得不偿失，完全没必要

另外，目前这么多用下来， 个人觉得lua的模式匹配已经完全足够满足日常的匹配需求，如果真有些复杂的匹配做不到的场景，稍微写几行lua脚本也能处理

而xmake设计初衷之一，也要保证程序尽量精简、少依赖，不能因为功能越加越多，随便一个需求，就引入个库进来，一会正则库，一会7z库，回头不知道又要加什么库进来，这么搞法迟早得完。

那lua自带的好，简单够用不用第三方

proxy_hosts和proxy_pac两个，还有优先级关系，对用户不太友好

--help有说明，另外在不友好，就两个选择，研究个几分钟就会了，回头文档也会说明，除非用户不看文档和help，那我管不了。连文档都不看的人，不友好就不友好了。

我也想到查文档。如果看了文档，觉得这个写法很自然很容易记住，那就更好了。

另外现在文档不是太方便查：

• 命令行查文档要靠人工浏览定位，有点累
• https://xmake.io 上搜索常常要搜几次才能准确定位，不知道为什么

[waruqi]

https://xmake.io 上搜索常常要搜几次才能准确定位，不知道为什么

这个没办法，用的也是docsify的第三方文档框架，也就是为了省事，没时间精力去折腾这些问题，你可以给docsify提issues，他们不解我也没办法。

而且之前用的docute问题更多，我已经花了很多时间，才彻底切到docisfy上面，算是比之前好用很多了，不想再折腾了，光写文档就已经很累了。。凑活着用吧。

[playgithub]

与其文档，不如GUI，先这样

[waruqi]

代理新增对 mirror url 的切换支持，可以自己配置切换到 fastgit 等镜像 github 站点加速包的下载，具体见：#1358