re-fix rust

[Mikachu2333]

问题描述

1. 修复 cargo 换源的一些问题 #288 有以下问题
   1. 对于 win 用户极不友好（刚需 sed 和 grep），且也没有原来的 doc 了
   2. 即使安装了 sed 和 grep 在win上也不能正确运行，正则似乎是写错了（不太确定），反正换源换成一坨乱码了
   3. 在 wsl 上似乎也有点小问题，我这里试了一下也没能正确换源
2. re-fix rust 换源提示有误 #281

方案与实现

1. 设置文件更改
   • ＋ gitignore 更新（适配 fw.c 中修改的测试步骤）
2. xy.h xy.h 增加str类的通用函数 #293
   • ＋ xy_str_find 用于查找str子串并返回 (bool, pos_begin, pos_end)
   • ＋ xy_str_take_until_newline 与上面的函数结合使用，用于获取从传入字符串的 [0] 开始直到下一个换行符的所有字符，主要在提取配置时使用
   • ＋ xy_file_to_str 用于读取文件并返回全部内容（以字符串形式返回），已处理所有换行符为 \n
3. core.c core.c 修改函数实现 #294
   • ＋ chsrc_log_overwrite 对覆写特别设置
   • ± chsrc_log_backup
     1. 更正笔误
     2. 更换变量名避免歧义
     3. 返回时规范化路径（好像没啥用不过）
     4. 我认为这个函数需要改进，应该直接返回一个文件路径一个操作句柄，或者干脆直接返回路径，句柄自己搞去，没有路径只有句柄太难受了
     5. 更新docs
   • ± chsrc_prepend_to_file impl for win
4. cargo.c
   • ＋ pl_note_get_src_default 把部分重复的通知逻辑抽出来了
   • ＋ pl_note_get_src_mirror 略
   • ± pl_rust_cargo_getsrc
     1. 去除所有需要 sed / grep 的代码
     2. 纯手工解析（感觉解析的代码 set 和 get 还能再抽象一个函数出来，但是懒得动了）
   • ＋ pl_write_rust_config 把重复的逻辑抽出来了
   • ± pl_rust_cargo_getsrc 用了很笨的办法，读取文件 -> 查找字段 -> 手动获取有效信息 -> 手动格式化，好消息是对所有系统都适用，因为mirror必须按官方规范来否则rust不识别，所以“获取有效信息”和“格式化”这两步也没啥额外问题，感觉现在错误处理有些太繁琐了，似乎可以精简
   • 格式化
5. rustup.c 格式化
6. rawstr4c.h 删除无用数据
7. fw.c core.c 修改函数实现 #294
   • ± 调整了测试的顺序，优化逻辑
   • ＋ 增加了相应的 tests
   • ± 根据上面修改的函数进行适配

其它

1. 我认为有必要把各种函数整理一下了……用的时候经常找不着（
2. 此外，根据 @ccmywish 此前的要求，此文件因为大幅修改（或者说回退）了你（ @happy-game ）的更改，因此您可能需要一起参与审阅
3. 此pr以及关联pr增加了大量函数，但极少对现有函数进行修改，因此与其它代码的逻辑关联性低，主要修改的只有一个 chsrc_prepend_to_file （Impl for win） 并且暂未发现问题。
4. 本地测试无误

[ccmywish]

辛苦了👍👍👍

我建议拆分提交，尤其是一些通用功能的实现，应该单独提出来。

[ccmywish]

@Mikachu2333 @happy-game

完全靠字符串去分析 rust 的配置文件，我觉得是非常辛苦的，也很难维护。以后用 toml json yaml 配置的文件只会越来越多，每一个都要这么努力的解析吗，我对此表示悲观。

我们已经用C语言实现了很多其实和 chsrc 的用途本身无关的内容，比如C语言自身函数不方便的问题，和跨操作系统的处理等等。已经消耗了我们大量时间和精力。而这些是能够在其他语言中直接就找到对应功能的。

我想，C语言实现的 chsrc 无法做的更多了，它更多的是实现这种 “半自动换源”，或者像 pip npm 这样，软件本身能够换源，我们只是简单做一个中介就好了——把想要的源和 “调用软件本身的功能” 关联起来。

我认为，提示用户进行简单的手动操作，就是把 chsrc 当成一种文档，chsrc as a document，它和全自动换源仅有一步之遥，从用户的便利性来看，只用多走很小的一步，但是对于维护者的实现来看，就是难以逾越的鸿沟。我们直接点说，那就是投资回报比太小了，没有什么价值。

如果非要坚持全自动换源，用其他语言重写可能是唯一的出路，如果是我，我可能会选择 Go 来重写，这是纯粹的从软件工程的角度来讨论的，从减少维护量来讨论的。然而我不喜欢 Go 语言，这让我对重写 chsrc 毫无兴趣，而且我们也说了，价值不大。如果有人愿意重写，我可以提供各种软性的帮助。

[ccmywish]

感觉无论用哪个语言写都是依赖地狱……毕竟需要同时解析 txt, ini, json, toml, yaml等等等等花样繁多的配置文件，总不能真全用正则吧，那又成正则地狱了……

不用正则啊，直接有现成的配置文件解析库，用起来应该很方便。但是C语言集成这些解析库，问题就太多了，那样也根本不能满足 chsrc 最想达到的目标——只要有 chsrc 源代码、编译器就能自行编译出来，这样就可以支持无限多平台，比如龙芯的机器。

拆分提交对我而言很痛苦

我知道，但是你可以 cherry-pick、squash等等，这个很大程度取决于你对 Git 的使用熟练程度。

包装成一个函数调用来的方便（且美观），那么我就会把那个函数实现

是的，这是正常的路径，但是就是因为你要抽函数出来，比如 append，此时你就应该立刻另开一个本地分支来开发，然后直接PR过来。

不想接受巨大的 PR 有这些原因：

1. review 的时候看的很累，因为是对着那个 review 的窗口看的，看起来比较吃力，尤其是内容一多，不知道某一处的代码是干嘛用的
2. 你的 commit message 比较简短和零碎，在这个PR里能大概看出来这些 message 的意义，但是一旦合并，这些 commit 单从 message 上看就不知道是在干什么。

比如， trim、format、get src 这些信息过于简单。而且像格式化这种步骤应当在开发过程中完成，而不是单独作为一个 commit .

3. 有一个很根本的问题，那就是贡献度的问题，当我看到有很多零碎的 commit 的PR的时候，我想的是直接 squash，这样就能有一个简单的历史，但是如果你提交了 30 个 commit，我直接 squash 掉，你就相当于只提交了一次，我觉得这是不合理的，至少要从表面上一定程度能够直接体现你所付出的这么多努力。所以此时我也不能 squash.

[ccmywish]

ChatGPT 对于 30个commit的看法：

你看最后的说法，和我上一条评论的最后一个观点是一致的，如果你不想拆分提交，就应该提前自行整理你的 commit，然后 PR 过来

[happy-game]

我想，C语言实现的 chsrc 无法做的更多了，它更多的是实现这种 “半自动换源”，或者像 pip npm 这样，软件本身能够换源，我们只是简单做一个中介就好了——把想要的源和 “调用软件本身的功能” 关联起来。

我认为，提示用户进行简单的手动操作，就是把 chsrc 当成一种文档，chsrc as a document，它和全自动换源仅有一步之遥，从用户的便利性来看，只用多走很小的一步，但是对于维护者的实现来看，就是难以逾越的鸿沟。我们直接点说，那就是投资回报比太小了，没有什么价值。

虽然我个人更倾向于安全的自动换源, 但从不同的配置文件格式来看确实很难实现，每次尝试使用正则处理 json, toml 等文件都十分头疼, 而且可读性极差, 让项目变得难以维护。从投入产出比来看这确实是最好的方案了。

[ccmywish]

可恶，怎么win和linux还不通用啊

现在的能跑通了吗？我没有环境验证。

[Mikachu2333]

测试均已通过，我认为可以merge了

[ccmywish]

另外再看一下 #294 的问题

[Mikachu2333]

本地测试 merge #298 #300 一切正常