在开发调试过程中预置一些调试功能和工具通常是有意义的，如预置telnet、gdb等，本文描述openubmc如何管理这些功能。

​

一个组件化的构建架构需要考虑扩展性，能够轻松适配不同OS、不同编译器甚至不同的芯片。采用二进制引入工具绝对不是一个明智的选择，所有非产品类的调试功能或工具建议按如下方式管理。

工具也是一个组件 ​

调试工具应该以可源码构建的conan组件形式引入，支持可源码构建、支持交叉编译、自动依赖管理、构建工具（make/cmake/gcc等知名且通用的除外）自管理特性，这样做可以明显的好处包括：

1. 可追溯、可升级、支持交叉编译，为openubmc提供长期支持，广泛适用于各种场景，持续产生收益；
2. 维护openubmc组件化通用的和解耦的架构，维护扩展性和灵活性。

功能有开关 ​

融入业务组件中的调试功能应该以特性形式控制可见范围，控制方式一般是构建类型(debug/release)，也可以根据需要扩展，不管如何都需要由conan包对外呈现特性开关，实现可控。

构建工程实现 ​

构建工程已支持软件包（supportE发布包、toGDP生产装备包）级实现组件裁剪和特性裁剪。

同时，考虑调试功能、工具的可见范围需要基于 某些条件，只有满足特殊条件的软件包或特性才会引入工具或组件，构建工程为此需要扩展支持条件引入功能，并预置常用条件，如根据build_type要求控制引入条件，具体条件可以扩展。

以下是manifest.yml中编写条件引入 组件 和 特性 的示例：

dependencies:
  - conan: "ssdp"
    condition:
      build_type: release
  - conan: "muparser"
    options:
      shared: true
    condition:
      build_type: debug
  - conan: "muparser"
    options:
      shared: false
    condition:
      build_type: release

上述示例演示了：

1. ssdp组件只在release条件下引入
2. muparser组件在debug条件下使用shared动态库
3. muparser组件在release条件下使用静态库

责任与分工 ​

调试功能和工具的引入涉及构建工程和业务述求方，相关责任与分工：

1. 构建工程提供扩展条件检查设计和实现，可为具体工具和功能编译构建提供指示。
2. 调试工具和调试功能引入按谁痛谁主动原则确定，一般为业务述求方，需要完成组件的源码引入和功能实现。