Closed flyingcys closed 3 weeks ago
ci好加吗?
关于这个打包的 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。
确实是一个正确的模式,可惜开源社区迭代可以更快速些,如果有更好的方式,后续也可以再推翻来过 😮💨
ci好加吗?
CI已经添加一个
关于这个打包的 issue,我以前建过一个 #9060 ,用于讨论 solution 和可行性。 但我最新的想法是不倾向于增加 prebuild。原因分析具体见 #9060 (comment)。后来也就没有继续这个工作了。
如果大家觉得引入 prebuild 的做法可以继续,那我也没有意见(这个 pr 我也看了,按这个思路做的改动本身没有什么大的问题),只是个人觉得这不是个好的 solution。
Anyway,其实对于一些 feature 的开发,我的建议是先建立 issue ,充分讨论后再开发和 pr。否则直接 pr 后再讨论要不要做的确是一件很尴尬的事情。
谁可以决定这个事情呢?可以拍个板。
当前pre-build 增加文件大小为2.9M空间。 之前也是因为有人提出在线下载并编译很浪费时间,也对网络有较大依赖,所以才修改为 pre-build方式。
采用预编译好的bin文件的方式,还有什么问题吗
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)
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0
代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up