你遇到的问题本质上是忽略了C/C++编译模型中编译单元的独立性——每个.cpp文件都是一个独立的编译单元，预处理、编译过程都是各自单独进行的，宏定义完全不会在不同编译单元之间自动共享。

为什么放在库目录里能正常编译？ #

当你把config.h放在库的头文件目录中，并且库的所有源码文件（比如myLibrary.cpp）和头文件都通过#include <config.h>引入了这个配置文件时，库的每个编译单元在预处理阶段都会加载config.h里的宏，所以SIZE_USER、CONDITION这些宏在编译库代码时是可见的，自然不会报错。

为什么放在用户目录就失效了？ #

当你把config.h移到main.cpp所在目录，只在main.cpp里引入它时：

• 只有main.cpp这个编译单元能看到config.h里的宏；
• 库的源码文件（比如myLibrary.cpp）是单独的编译单元，它在预处理时根本没有引入用户目录下的config.h，所以完全不知道SIZE_USER这些宏的存在，编译时自然会报错。

你可能误以为main.cpp里的宏会“传递”给库代码，但实际上编译单元之间是完全隔离的——除非你主动让库的编译单元也能获取到这些宏。

解决方案 #

根据你的设计思路（让用户自主维护配置文件），可以采用以下几种方案：

1. 让库的所有编译单元强制依赖用户配置文件 #

修改库的主头文件myLibrary.h，在开头加上：

#include "config.h"

然后要求用户：

• 将config.h放在编译器能搜索到的路径（比如main.cpp所在目录）；
• 编译时通过编译器选项（比如GCC的-I，MSVC的/I）指定用户配置目录的路径，确保库的源码文件在编译时能找到config.h。

这样不管是main.cpp还是库的myLibrary.cpp，在预处理阶段都会加载同一个config.h，宏定义就能在所有编译单元中生效。

2. 通过编译器选项传递宏定义 #

让用户在编译时通过-D选项（GCC/Clang）或/D选项（MSVC）直接传递宏，比如：

gcc -DSIZE_USER=5 main.cpp myLibrary.cpp -o myApp

这种方式不需要头文件，所有编译单元都会自动看到这些宏。缺点是用户需要手动管理编译选项，不如头文件直观。

3. 约定用户在引入库前定义宏 #

要求用户在main.cpp中先定义所有必要的宏，再引入库头文件：

#define SIZE_USER 5
#include <myLibrary.h>
// 用户代码...

同时在库的头文件中添加检查，确保宏已定义：

#ifndef SIZE_USER
#error "请先定义SIZE_USER宏！"
#endif

int variable1[SIZE_USER];
#if SIZE_USER>3
#define CONDITION 1
#else
#define CONDITION 0
#endif

这种方式不需要额外的配置文件，但用户每次使用都要手动写宏定义，适合宏数量较少的场景。

额外注意：#include的搜索路径 #

你示例中用了#include <config.h>，这种写法会让编译器优先搜索系统库目录和编译器指定的库路径，而不是当前源文件所在目录。如果config.h在main.cpp所在目录，应该用#include "config.h"，这样编译器会先搜索当前目录，找不到再去系统目录查找。

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