两种Makefile OBJ变量定义方式为何导致嵌入式构建产物差异？

这两种定义方式的核心差异主要体现在三个方面，也是导致你编译产物不一致的关键原因：

• 文件范围的可控性
  OBJ := ${SRCS:.c=.o}是批量后缀替换，会把SRCS里所有.c文件对应的.o都纳入目标列表。如果你的SRCS是通过通配符（比如$(wildcard *.c)）生成的，很容易混入测试代码、临时调试文件这类IDE不会编译的.c文件，对应的.o被链接后，自然会让最终的.bin/.hex和IDE产物不一样。而IDE逐个指定.o的方式是精确枚举，只包含明确需要的目标文件，完全不会引入意外的编译单元。

• 文件顺序的确定性
  链接器对目标文件的顺序是敏感的——比如全局变量的初始化顺序、符号解析的优先级，甚至某些嵌入式平台的启动流程都和.o的链接顺序挂钩。用后缀替换的话，SRCS的顺序如果来自通配符，不同系统（比如Linux和Windows）或者不同目录下的文件排序规则可能不一样，导致OBJ里的.o顺序波动，最终二进制内容产生差异。而逐个指定.o的方式是固定死顺序的，不管环境怎么变，链接时的文件顺序完全一致，产物自然可重复。

• 编译规则的一致性
  Make默认有一套隐式编译规则，如果你没有在自定义Makefile里明确覆盖所有编译参数（比如特定的宏、优化级别、芯片架构参数），用后缀替换生成的.o可能是通过默认规则编译出来的，和IDE里为每个.o指定的专属编译命令（比如带-DXXX、-O2这类参数）不一致。单个.o的内容不同，最终链接出来的产物肯定也不一样。而IDE逐个指定.o的方式，通常会给每个目标绑定明确的编译规则，彻底避免了隐式规则的干扰。

你改成IDE的方式后，这些变量因素都被消除，所以产物和IDE完全一致。

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