34 lines
3.7 KiB
Markdown
34 lines
3.7 KiB
Markdown
# RES、SDK 与表述边界
|
|
|
|
## 开发源文件
|
|
|
|
BSP 工作包的人工开发改动只写入当前 `EmxRes/<项目名>` 及其 staging 项目。Pinmux、GPIO、DTS/DTSI、defconfig、媒体内存、分区和项目同步脚本均在 RES 中维护；参考项目只读。SDK 文件、SDK 软链接和 `EmxRes/tools` 共享构建脚本不属于该修改范围。
|
|
|
|
确需修改 SDK 驱动、公共配置或共享构建工具时，先说明已确认的原因、所有权、精确文件和验证方式，作为独立工作包处理。读取 SDK 的授权和当前 BSP 工作包的批准均不自动授予这些编辑权限。
|
|
|
|
## SDK 只读调查
|
|
|
|
用户明确给出 SDK 根目录后，只读取与当前板型和问题相关的映射文件、必要 include 链及实现。调查所得的 SDK 路径用于证明映射或解释行为，不放入人工开发修改清单。
|
|
|
|
项目与 SDK 内容不同可能来自上次构建、已有工作或基线差异。先说明证据及对当前任务的影响，不能仅凭内容不同认定 SDK 需要修复。发现软链接指向公共文件时，报告原生同步会写到哪里；不默认提出替换 SDK 软链接、重建目录、清理、恢复或备份后覆盖的方案。若未确认的已有改动将被本次同步覆盖，停止该构建并请用户决定，继续不依赖该问题的 RES 工作。
|
|
|
|
## 原生编译的实际写入
|
|
|
|
已确认工作包中的标准全量编译会执行项目原生配置同步，并写入 SDK 板级目标、生成配置、头文件、DTB、缓存和编译产物。配置同步可能穿过软链接写入公共目标；这些也是 SDK 的真实文件写入，必须按已核对的构建链如实说明。源文件的维护位置仍为 RES。
|
|
|
|
这项构建授权只覆盖原生工具已说明的动作。不得为了编译顺利或让 SDK 看起来没有变化，额外编辑 SDK、改造软链接、注入同步逻辑、做完后恢复 SDK 配置，或修改共享构建脚本。项目同步脚本的修改也须列入 RES 实施方案，并说明其 SDK 写入效果；不能利用 RES 脚本扩大 SDK 修改范围。
|
|
|
|
按用户已确认的语义处理“只改 RES”：若指开发改动只在 RES，保留已授权的原生编译，不为标准同步重复请求确认；若用户明确要求 SDK 在整个过程严格只读，而现有原生工具必须写入 SDK，则停止该构建，说明具体冲突并让用户选择继续 RES 静态工作或另行处理构建环境。不能自行改造 SDK 来消除冲突。
|
|
|
|
## 方案与结果的说法
|
|
|
|
方案和报告分别列出三项：当前 RES 项目的开发改动、SDK 的只读核对映射、原生构建将执行或已经执行的文件写入。SDK 存在多份同名文件时，使用精确路径，并标明软链接及其真实目标。
|
|
|
|
- 开发阶段可以说“开发改动只写入 RES；SDK 仅用于只读核对”。
|
|
- 构建阶段应说“原生编译会将 RES 配置同步到 SDK，并生成编译文件”。不能笼统承诺“SDK 不会发生任何修改”。
|
|
- 不能将“构建同步到 SDK 的六个目标文件”说成“需要人工修改 SDK 的六个文件”。
|
|
- 区分计划、已经执行和检查通过；只有读取证据时不能说已经同步，命令或复制成功不能代替生效配置、镜像和设备验证。
|
|
- 用户纠正范围时，立即更新受影响的方案及记录；已知的路径、决定和授权继续使用。不要把一次范围澄清变成重复索要整套信息或重新审批已授权的标准构建。
|
|
|
|
报告原生构建写入时，说明实际命令、配置来源、同步目标和生成物；没有执行的同步、编译及设备验证明确标为未执行。只有确认整个过程没有 SDK 写入时，才可以声称 SDK 目录未变化。
|