1.4.5 产物输出与安装规则 (Artifact Output & Installation Rules)

审计综述：项目采用了**“集中式输出”策略，极大地方便了开发阶段的调试与运行。然而，主构建脚本完全缺失了安装规则 (install)**，这意味着无法通过 make install 将产物打包或部署到系统目录，当前仅限于在构建目录（Build Tree）内运行。

1. 输出目录布局 (Output Directory Layout)

关键性：P1
策略解析：
- 集中管理：通过设置 CMAKE_RUNTIME_OUTPUT_DIRECTORY 等变量，强制将所有生成物归档到 ${CMAKE_BINARY_DIR}/bin 和 ${CMAKE_BINARY_DIR}/lib。
- 优势：
  - 避免了编译产物散落在源码目录深处（In-source build pollution）。
  - 简化了 RPATH 的管理，因为所有库都在同一个相对路径下。
  - 方便了 numactl 等工具的调用路径书写（如 1.3.3 中所示）。

探测依据：

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

2. 安装规则状态 (Installation Rule Status)

关键性：P2 (Missing)
策略解析：
- 现状：grep "install(" 显示主项目（app 和 signal_lib）未定义任何安装规则。仅有的安装指令来自第三方依赖（GTest）和 SDK 内部文件。
- 影响：运行 make install 将不会复制雷达主程序或库文件。对于目前的 Demo / 原型开发阶段，这是可接受的。
- 改进建议：若项目进入生产交付阶段，必须补充 install(TARGETS main_app DESTINATION bin) 等指令，以便生成发布包（RPM/DEB）。

探测依据：

grep -r "install(" …
# (无主项目相关输出)

3. 调试符号与剥离策略 (Debug Symbol Strategy)

关键性：P2
策略解析：
- 物理状态：file 命令显示 not stripped，说明符号表（Symbol Table）保留，可支持 nm 或 gdb 查看函数名堆栈。
- 调试信息：readelf 未找到 .debug 段。这是因为当前处于 Release 模式（-O3 -DNDEBUG），编译器默认不生成 DWARF 源码级调试信息。
- 结论：这是标准的 Release 构建产物，兼顾了性能（优化开启）和基础可维护性（崩溃时能看到函数名）。
探测依据：
```
file …/main_app
… not stripped
```

至此，我们完成了对 1.4 构建系统 的全方位审计。我们确立了该项目的**“构建基线”**：