C源码#include前定义的宏为何未被头文件预处理指令识别？

这个反常现象本质是两个编译层面的基础逻辑没对齐，和预处理器“行为不一致”没有关系：

• C预处理器的宏作用域是严格单翻译单元隔离的
  C语言的编译是按单个.c文件（及其递归包含的头文件，合称为翻译单元）独立做预处理、编译生成目标文件的，在一个翻译单元里#define的宏，完全不会影响其他独立编译的翻译单元。
  你在check_blah.c里写的#define UNIT_TEST 1，仅在编译check_blah.c时生效。而blah.o是单独编译blah.c生成的，这个编译过程中没有定义过UNIT_TEST，所以预处理器处理blah.c里的u_static宏时，必然走#define u_static static的分支，最终foo在blah.o里就是静态函数——链接阶段不会修改目标文件里已经生成的函数绑定属性，所以你用gdb看它永远是静态的。
  你做的SPEEP宏对照实验，只能证明check_blah.c这个翻译单元里UNIT_TEST处于定义状态，完全不能说明编译blah.c时的宏状态。
• Makefile笔误放大了问题的迷惑性
  你写的blah.o编译规则存在低级错误：gcc -c blah.c -o blah.h本该输出目标文件blah.o，你错误指定输出为blah.h，等于每次执行这条规则都会直接覆写你的头文件，且根本不会生成正确的blah.o。后续链接阶段实际用的是目录里残留的、之前未开启UNIT_TEST编译出的旧版blah.o，这也是你调整宏位置时偶尔会看到“生效”假象的原因——本质是残留文件碰巧匹配了你的预期。

当你把#define UNIT_TEST 1写到blah.h头部后，不管是编译check_blah.c还是编译blah.c，只要包含了blah.h就会自动定义UNIT_TEST，两个翻译单元的宏状态完全对齐，blah.c里的u_static会被正确展开为空，foo自然就会被编译为非静态的全局函数。

• 控制跨翻译单元编译行为的宏，不要在单个.c文件里定义，应该在Makefile的全局编译参数中通过-DUNIT_TEST传递，保证所有关联翻译单元的宏状态一致。
• 修正Makefile笔误，将blah.o的编译规则改为gcc -c blah.c -o blah.o，避免覆写头文件、生成错误目标文件。

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