为何GCC需手动指定同目录.c文件？能否让其自动查找依赖？

核心原因：头文件≠实现文件 #

你用#include "dir/subdir/file.h"只是告诉编译器「这个函数/变量的声明在这里」，编译器会把头文件里的内容直接复制到当前.c文件里，但头文件里只有声明（比如void func();），真正的代码实现（比如void func() { ... }）是在同目录的file.c里的。

C语言采用分离编译模型：每个.c文件都是独立的「编译单元」，编译器会先把每个.c编译成目标文件（.o），最后再把所有目标文件链接成可执行文件。GCC不会因为你include了某个头文件，就自动去搜索并编译对应的.c文件——它根本不知道头文件和哪个.c对应，毕竟一个头文件可能被多个.c引用，也可能没有对应的.c（比如纯宏定义的头文件）。

其他语言（比如Python、Java）要么是解释执行时自动加载依赖模块，要么有内置的模块管理机制帮你处理文件查找，但C语言是更底层的编译型语言，编译和链接步骤完全暴露给开发者，默认不会做自动依赖扫描。

让GCC自动处理依赖的方法 #

1. 使用Makefile（最常用）

写一个简单的Makefile，定义好可执行文件依赖的所有.c文件，以后只需要敲make命令，它会自动编译需要更新的文件：

# 定义目标文件main，依赖main.c和dir/subdir/file.c
main: main.c dir/subdir/file.c
	gcc $^ -o $@  # $^代表所有依赖文件，$@代表目标文件

如果项目变大，可以用gcc -MM main.c自动生成依赖关系，写入Makefile，避免手动维护路径。

2. 使用CMake（适合大型项目）

CMake是跨平台的构建工具，它会自动扫描指定目录下的源文件，生成对应的Makefile或者Visual Studio工程。比如创建CMakeLists.txt：

cmake_minimum_required(VERSION 3.10)
project(main)
# 添加所有需要编译的源文件
add_executable(main main.c dir/subdir/file.c)

然后执行以下命令构建：

mkdir build && cd build
cmake ..
make

后续只需要在build目录敲make即可，CMake会自动处理依赖变化。

3. 用Shell脚本简化命令

如果只是小项目，不想用构建工具，可以写个简单的Shell脚本，把所有需要的.c文件列进去，每次执行脚本就行：

#!/bin/bash
gcc main.c dir/subdir/file.c -o main

保存为build.sh，赋予执行权限chmod +x build.sh，以后运行./build.sh就可以了。

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