开源之夏-18
前几天在社区问关于铜锁SDF模块构建项目的问题：
今天收到了回复。分析一下：
@董海玄 SDF 库集成配置
Tongsuo 项目已经内置了对 SDF 库的支持。 Configure:1054-1061 您可以通过以下配置选项来指定 SDF 库的路径：
–with-sdf-lib=PATH: 指定 SDF 动态库的路径
–with-sdf-include=PATH: 指定 SDF 头文件的路径
编译配置步骤
启用 SDF 支持： Configure:949-952
./Configure –enable-sdf-lib-dynamic –with-sdf-lib=/path/to/gmssl/lib –with-sdf-include=/path/to/gmssl/include
动态库加载机制： sdf_lib.c:92-118
Tongsuo 使用 DSO（Dynamic Shared Object）机制来动态加载 SDF 库，默认库名为 “sdf”。
SDF 命令行工具
编译完成后，您可以使用 openssl sdf 命令来测试 SDF 功能： build.info:78-80 sdf.c:113-140 SDF 命令行工具支持多种操作，包括：
- SM2 密钥生成和管理
- 加密解密操作
- 数字签名
- MAC 计算
依赖关系配置 Configure:713-714 配置系统会自动处理 SDF 库的依赖关系，确保在启用 sdf-lib 时同时启用 sdf-lib-dynamic。
验证集成
编译完成后，您可以通过以下方式验证 SDF 库是否正确集成：
- 检查 openssl sdf 命令是否可用
- 测试基本的 SDF 操作，如设备打开和会话创建
- 验证与 GmSSL 软实现的兼容性
Notes
确保您的 GmSSL 动态库实现了标准的 SDF API 接口，包括 SDF_OpenDevice、SDF_OpenSession 等函数。 sdf.h:62-117 Tongsuo 的 SDF 实现遵循 GM/T 0018-2012 标准。
上边内容感觉是AI生成的(帮他补回来了了markdown格式😉)，因为现在铜锁不支持SDF(不然也不会有我的事了)
而且开了编译选项也不能用，因为TSAPI写穿了，直接依赖厂商库头文件。没插硬件会编译报错。
但是这引导我去花时间理清铜锁的构建系统方式，perl脚本构建逻辑。
项目总Configure：
- 启用模块的选择(配合00-base-templates.conf解析成宏，配合C程序完成)
- 动态库路径传入选项解析 => -L
- SDF头文件路径解析(让编译器能找到sdf的头文件) => -I
- 程序的链接库名 => -l
- etc
分立模块的build.info
完成模块间的依赖指定
你的疑问很有代表性。OpenSSL/Tongsuo 采用这种“分散式”build.info 设计，主要有以下考虑：
1. 模块化和可维护性
每个子目录（如 crypto/sdf）有自己的 build.info，便于各自维护和扩展。这样新增、修改、删除某个模块时，只需关注本目录的 build.info，不影响全局。
2. 依赖关系清晰
虽然主 build.info（如 crypto/build.info）会汇总依赖，但每个子模块也要声明自己对 libcrypto 的依赖，确保即使单独构建该模块也能正确链接。这种“冗余”是为了防止依赖遗漏。
3. 自动化脚本处理
Perl 脚本会自动收集所有 build.info，统一生成最终的 Makefile/Ninja 文件。分散声明有利于自动化工具灵活组合和管理构建目标。
4. 兼容性和灵活性
有些模块可能被多个上层模块复用，分散声明依赖可以让构建系统根据实际需要灵活组合目标，支持不同平台和构建方式。
总结：
这种设计牺牲了一些集中性，但换来了模块独立、易维护、自动化友好和灵活适配多平台的能力，是大型跨平台项目常见的构建策略。