Windows下GCC在终端及VS Code编译多C文件与头文件的操作是否正确

为什么相同结构的项目有的需要加-I参数才能找到头文件 #

gcc处理#include "xxx.h"格式的头文件时，优先搜索执行gcc命令时的当前工作目录，而非.c源文件本身的存放目录。你之前编译失败的场景，大概率是执行gcc命令时的终端工作路径，和头文件header.h的存放路径不一致，比如你在上级目录执行gcc 项目目录/file.c 项目目录/main.c -o main，此时gcc的工作目录是上级目录，不会自动去项目子目录里找头文件，加-I 项目目录之后就把对应路径加入了头文件搜索队列，所以可以正常编译。
如果不想每次都加-I参数，也可以在写#include时使用相对于当前工作目录的相对路径引入头文件，但这种写法耦合性高，项目目录结构调整后需要批量修改引入路径，不推荐使用。

你当前的task.json配置是否正确 #

配置是正确的，可以正常满足多.c文件项目的编译需求，几个核心参数的作用都符合预期：

• ${workspaceFolder}\\*.c会自动编译工作区根目录下所有.c源文件，不需要手动逐个添加源文件参数
• -I${workspaceFolder}将工作区根目录加入头文件搜索路径，避免了工作目录和项目目录不一致导致的头文件找不到问题
• -g参数保留调试信息，方便后续用gdb调试程序

更简便的实现方案 #

根据项目大小可以选择不同的方案：

• 小型项目（10个以内源文件）：你当前的配置已经足够简便，不需要额外调整，每次修改后直接执行构建任务即可完成全量编译
• 中等规模项目：可以编写Makefile管理编译逻辑，只编译修改过的源文件，大幅提升编译速度，示例Makefile内容如下：

CC = gcc
CFLAGS = -g -I.
OBJ = main.o file.o

main.exe: $(OBJ)
	$(CC) $(OBJ) -o main.exe

%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

clean:
	del *.o main.exe

编写完后只需要在终端执行make命令即可完成编译，执行make clean可以清除编译生成的中间文件和可执行文件

• 大型项目/跨平台项目：可以使用CMake管理构建流程，自动生成对应平台的构建配置，适配MinGW、MSVC等不同编译器，维护成本更低。

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