在C项目中通过#include源文件选择API实现是否为不良实践？

你的思路确实能简化构建配置，但这种直接#include .c文件的方式存在不少值得警惕的问题，属于C语言里的不良实践，具体理由如下：

• 调试与编译效率问题：
  多个源文件被合并成一个编译单元后，调试时无法直接定位到原implementation_x.c的代码行，编译器报错也只会指向implementation.c的行号，增加问题排查难度。另外，每次切换实现都要重新编译整个合并后的单元，而分开编译的方式可以利用增量编译，只重新编译选中的实现文件，节省编译时间。

• 符号冲突风险：
  如果不同实现文件中存在同名的静态变量或内部函数（虽然对外API统一，但内部实现可能有重复命名），合并到同一个编译单元后会触发重定义错误；而分开编译时，静态符号的作用域仅限于各自的源文件，不会有这个问题。

• 违背C语言的编译惯例：
  C语言的标准实践是头文件（.h）存放声明，源文件（.c）存放实现，直接#include源文件打破了这种分工，会让后续维护者困惑，降低代码的可读性和可维护性。

• 构建灵活性受限：
  后续新增实现时，除了添加新的implementation_x.c，还必须修改implementation.c中的宏分支逻辑；而原CMake方式只需要在构建配置中新增对应选项和源文件，无需修改现有代码。

更优的替代方案：CMake条件编译 #

无需新增implementation.c，直接在CMake配置中通过选项选择要编译的源文件，既简化用户操作，又保留所有编译优势：

# 定义可选的实现选项
option(IMPLEMENTATION_SEL_1 "使用API实现1" OFF)
option(IMPLEMENTATION_SEL_2 "使用API实现2" OFF)

# 基础源文件列表
set(SOURCES api.h)

# 根据选项添加对应实现文件
if(IMPLEMENTATION_SEL_1)
    list(APPEND SOURCES implementation_1.c)
elseif(IMPLEMENTATION_SEL_2)
    list(APPEND SOURCES implementation_2.c)
else()
    message(FATAL_ERROR "未选择有效的API实现")
endif()

# 构建目标
add_executable(your_project ${SOURCES})

用户只需在配置CMake时指定-DIMPLEMENTATION_SEL_1=ON，就能自动选中对应的实现，完全不需要修改代码，同时保留了增量编译、调试精准定位的优势。

内容的提问来源于stack exchange，提问作者SleepyJack