[features] 增加独立工程模式的功能

[BernardXiong]

想法说明

目前RT-Thread的方式，在开发的时候会变成更多以BSP为主的方式，而对于工程业务逻辑，当不需要过多关注板卡情况时，并不是那么友好。而当所有构建脚本都使用scons脚本，Python脚本时，会太编程化（灵活度足够高，但不利于IDE、UI工具配置模式）

希望可以做到：

• 可以创建独立工程；
• 工程可以灵活选择RT-Thread版本（及路径）；
• 工程可以灵活切换芯片，驱动；
• 支持到附带的json配置文件模式，这样更利于集成到一些UI工具配置中；

挑战

目前在RT-Thread的一些BSP中，也引入了SDK_LIB，链接脚本，输出产物名称也都统一，这些都会在一定层面影响到统一化支持。

[ThinkCodeStudio]

想法说明

目前RT-Thread的方式，在开发的时候会变成更多以BSP为主的方式，而对于工程业务逻辑，当不需要过多关注板卡情况时，并不是那么友好。而当所有构建脚本都使用scons脚本，Python脚本时，会太编程化（灵活度足够高，但不利于IDE、UI工具配置模式）

希望可以做到：

• 可以创建独立工程；
• 工程可以灵活选择RT-Thread版本（及路径）；
• 工程可以灵活切换芯片，驱动；
• 支持到附带的json配置文件模式，这样更利于集成到一些UI工具配置中；

挑战

目前在RT-Thread的一些BSP中，也引入了SDK_LIB，链接脚本，输出产物名称也都统一，这些都会在一定层面影响到统一化支持。

我现在的工作流

我现在使用的是 env + clion 开发 5.1.0
我本人是从高级编程语言开发一直学到嵌入式的, 我的想法更偏向应用软件开发

我的想法

在实际开发流程中, 我需要先安装 env 工具, 再下载源码, 删除bsp其他的芯片和板卡工程, 保留用到的模板工程

我希望env工具能帮我下载源码, 并增量添加bsp工程, 再加上上面的功能

我认为RTThread Studio的问题

版本: 2.2.7
优点:

• 开箱即用, 界面化配置
  缺点:
• 每次创建工程都有 RTT 源码, 导致不同工程有大量的重复代码
• 基于eclipse的工具开发体验很烂
• 代码高亮提示不好, 我在找那个变量使用时需要用"查找"
• 代码提示不好
• 拼写检查不好, 我拼错了没有提示
  ...

我认为env的问题

版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

我对开发工具的设想

以我现在使用的clion举例
首先是跨平台, 其次是可在系统终端使用, 然后具体的细节可参考 rust 的 cargo 工具
然后终端程序的好处是可以配合其他脚本语言去控制工程的配置编程和适配
整合功能, 我不需要去做复杂的环境配置, 我不需要为了开发不断的切换不同的工具
我希望这个工具整合了源码下载, 工程创建, 代码编译, 下载调试(最好支持远程调试, 无线调试)
由于嵌入式开发对板子强相关, 有时候程序是一套程序, 但是板子有多个型号, 在编译中最好可选择编译配置文件,

我希望搭配终端工具会有配套的vscode 和 clion 插件, 但插件功能不能太复杂, 点名批评其他厂商的插件, 比如esp等的插件, 在vsc里做的和独立软件一样, 为什么不从vscode里分离出去, 我的vsc不只做他家的活, 做出能识别工程, 编译, 下载调试就够了, 如果增强的化也加强对编码体验的优化.

我知道图形界面开发考虑到大部分人, 但是图形界面对我来说学习成本高, 而且不像终端工具那么的灵活

[BernardXiong]

我认为env的问题
版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

这点可以展开说说吗？目前的env是可以做到了工具链自动探测，或者用户自己配置亦可。然后可能的还包括RTT_ROOT？所以在最前面说的，希望有份配置的json文件，由这份配置文件来指定RTT_ROOT在哪里，进而还包括，如果BSP、驱动并不需要当前工程带，也可以有BSP_ROOT（也包括SDK_ROOT，如果有的话）指向到对应位置。然后这份json配置文件可以在vscode中打开，直接使用UI方式进行配置

[BernardXiong]

这个图更希望是类似这样的，env做为独立的命令行工具支撑基础设施。而 vscode扩展 ➕ env的方式，形成一个简单易用的工具。当然因为env的基座在这里，所以也可以和其他的IDE进行配合，包括在env命令的基础上加入其他的命令，来做构建也好，做创建工程也好等等的。

[ThinkCodeStudio]

我认为env的问题
版本: 1.5.2
整体非常满意
只有一点不满意的是 env 工具不能配置进环境变量, 这导致了我在使用clion开发时还要打开env软件切换软件使用, 不能在clion内部的终端使用

这点可以展开说说吗？目前的env是可以做到了工具链自动探测，或者用户自己配置亦可。然后可能的还包括RTT_ROOT？所以在最前面说的，希望有份配置的json文件，由这份配置文件来指定RTT_ROOT在哪里，进而还包括，如果BSP、驱动并不需要当前工程带，也可以有BSP_ROOT（也包括SDK_ROOT，如果有的话）指向到对应位置。然后这份json配置文件可以在vscode中打开，直接使用UI方式进行配置

我可以理解的就是有一个json格式的配置文件, 然后在VSCode中打开这个文件显示UI界面?(类似于jupyter插件) 如果不是, 而且在插件中设置带UI界面我是不推荐的, 类似于esp的工具

esp这种方式做成一个插件不如直接改vscode成一个专用IDE(类似于AMD Vitis 2024版), 毕竟vscode是一个通用编辑软件, 我并不希望在vscode中加入IDE, 因为这会影响我使用VSCode做其他事.
所以如果做VSCode插件的话, 功能一定要简单, 面向文件的; 如果想让VSCode管理工程集成开发, 那就基于VSCode改出一个新软件. (也可以考虑基于IntelliJ IDEA改, 就像 Android Studio)

然后我不满意的是env现在是一个独立的终端应用软件, 其使用的还是 scons, menuconfig这些命令行工具, 我想有一个命令行工具去整合这些工具, 包括了项目的创建, 配置, 编译和调试, 然后这个命令行工具还是安装即用的(和RTThread Studio功能差不多, 不过是 控制台应用程序), 就直接在系统终端应用里就可以使用(比如 powershell, Windows terminal), 还有VSCode软件内的终端.

这个图更希望是类似这样的，env做为独立的命令行工具支撑基础设施。而 vscode扩展 ➕ env的方式，形成一个简单易用的工具。当然因为env的基座在这里，所以也可以和其他的IDE进行配合，包括在env命令的基础上加入其他的命令，来做构建也好，做创建工程也好等等的。

还是打算把源码和SDK放在工程里吗? 我希望的是把我不关心的代码都不加入我的工程中, 因为我的代码也在做版本管理, 源码本不是我写的代码, 加入我的工程就会造成我的工程体积变大.
我也不希望把三方包放到的我的工程里, 因为有的时候我已经使用过一个软件包了, 那我再创建一个工程后可以继续使用这个软件, 不需要重新下载, 也不要进入我的版本管理.

还有如果我每次创建一个新的工程, 使用的都是同一版本的源码就会造成工程与工程之间有代码重复, 所以我的想法是在同一源码版本下管理不同的工程, 最好的情况是将我们应用项目和系统源码三方包完全隔开, 其实我的想法就是像linux一样 应用开发和系统开发完全隔开.

然后我的工程中有一个配置文件, 里面描述了我使用的是哪个版本的系统, 哪个芯片, 哪个版本的HAL库和BSP, 最好在这些库的代码里都添加版本宏定义, 让我编写不同本版芯片的代码, 然后命令行工具会读取这个文件再整合编译成固件

[BernardXiong]

VSCode插件的话, 功能一定要简单

这个是希望追求的目标，不过一步步来吧，可能会显得麻烦，也有可能从简到繁再到简。

还是打算把源码和SDK放在工程里吗?

并不是，而是通过配置指向到对应的路径位置。

想法是在同一源码版本下管理不同的工程

如果是这样，则需要自行手动来构造整体目录结构了。这样的方式或许就有些类似于rt-thread本身的发布版本，这个时候或许可以是在配置上设置当前默认的工程是哪个，可以在根目录下build，或也可以生成workspace结构直接切换过仅显示对应的文件。

感觉到的一点是，这个过程是逐步的，可能从简到繁再到简，最终好用。需要一个过程