开发依赖C代码的R包：需包含.c文件还是仅.so文件？

嘿，这个问题其实挺关键的，尤其是对刚接触带编译代码的R包开发者来说！我来给你拆解下不同场景的要求：

一、要发布到CRAN或公开分发的包：必须包含.c源文件，不能只放.so #

• CRAN的核心要求之一是包要可重现构建，而.so是平台特定的二进制文件——Linux的.so没法在Windows或macOS上用，反之亦然。如果只提交.so，其他平台的用户根本没法正常安装你的包。
• 正确的做法是把所有C源文件放在包的src/目录下，R的构建工具（比如devtools::build()）会在用户安装时自动编译生成对应平台的二进制文件，完美适配不同系统。
• 额外提醒：如果你的C代码依赖系统库（比如libcurl这类），一定要在DESCRIPTION文件里用SystemRequirements字段明确说明，比如SystemRequirements: libcurl-dev，方便用户提前安装依赖。

二、本地/团队内部私用的包：可以暂时用.so，但强烈不推荐 #

• 如果你们团队所有人都用同一个操作系统（比如都是Ubuntu），只放.so确实能正常加载使用，但这是非常脆弱的方案：
  • 一旦有人换了系统（比如换成macOS），包直接失效；
  • 后续要修改C代码时，没有源文件根本无从下手；
  • R在加载包时，如果发现src/下有.so会直接使用，但如果源文件更新了，R不会自动重新编译，很容易出现“代码改了但效果没更新”的诡异问题。

三、几个关键注意事项 #

• 所有C/C++源文件务必放在src/目录下，这是R包构建工具约定的位置；
• 如果需要自定义编译参数（比如链接第三方库、指定编译器选项），可以在src/下创建Makevars（适用于Linux/macOS）或Makevars.win（适用于Windows）文件来配置；
• 用devtools::check()检查包时，如果没包含源文件，大概率会抛出错误，这也是CRAN审核不通过的常见原因。

总的来说，不管是公开分发还是内部使用，优先包含.c源文件才是规范且可持续的做法，只放二进制文件只是权宜之计，长远来看会给维护和协作埋下不少坑。

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