rt-thread
rt-thread copied to clipboard
RT-Thread
[bsp/cvitek] Update packaging method
Use pre-build files to reduce compilation time
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
修改cvitek 打包方式为预编译文件
你的解决方案是什么 (what is your solution)
请提供验证的bsp和config (provide the config and bsp)
- BSP:
- .config:
- action:
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
- [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
- [x] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
- [x] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
- [x] 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
- [x] 没有垃圾代码，代码尽量精简，不包含
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up - [x] 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
- [x] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
- [x] 代码是高质量的 Code in this PR is of high quality
- [x] 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 https://github.com/RT-Thread/rt-thread/issues/9060#issuecomment-2282966644。后来也就没有继续这个工作了。
如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。
Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。
谁可以决定这个事情呢？可以拍个板。
关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。
如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。
Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。
谁可以决定这个事情呢？可以拍个板。
建立 issue ，充分讨论后再开发和 pr。 确实是一个正确的模式，可惜开源社区迭代可以更快速些，如果有更好的方式，后续也可以再推翻来过 😮💨
关于这个打包的 issue，我以前建过一个 #9060 ，用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。
如果大家觉得引入 prebuild 的做法可以继续，那我也没有意见（这个 pr 我也看了，按这个思路做的改动本身没有什么大的问题），只是个人觉得这不是个好的 solution。
Anyway，其实对于一些 feature 的开发，我的建议是先建立 issue ，充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。
谁可以决定这个事情呢？可以拍个板。
当前pre-build 增加文件大小为2.9M空间。 之前也是因为有人提出在线下载并编译很浪费时间，也对网络有较大依赖，所以才修改为 pre-build方式。