我想知道是否有可能在配置内核后知道哪些文件将被编译以及以什么顺序编译？
我想知道这一点，因为我对根据架构的构建过程的变化感兴趣，并且我不想拥有与架构一样多的工具链......
谢谢
【问题讨论】：
标签： build-process makefile linux-kernel
完成重新编辑：
您可以修改内核源代码中的 Make 过程以使用
-n, --just-print, --dry-run, --recon
这样做的最终结果是永远不会调用编译器或任何可执行文件。它只是伪造它并告诉你它会做什么。
选项并从中获取文件而不构建源代码。这可能就像在 shell 中设置 MAKE 环境以使用上述选项一样简单。然后只需 grep 出所有涉及 .c 和 .h 文件的编译器命令。下载 2.6.29.2 的内核源代码以了解如何执行此操作。编辑来。
祝你好运
回复你的进展情况。也许发布shell脚本！ :)
跟进：
2.6.29.2 内核源代码的第 13 行包含在 /2.6.19.2/Makefile 中
# Do not:
# o use make's built-in rules and variables
# (this increases performance and avoids hard-to-debug behaviour);
# o print "Entering directory ...";
MAKEFLAGS += -rR --no-print-directory
# We are using a recursive build, so we need to do a little thinking
# to get the ordering right.
编辑MAKEFLAGS 变量以包含dryrun 标志应该 允许您保存特定make 配置的输出，然后稍后对其进行grep。 ala make > save.txt
我改成了
MAKEFLAGS += -rR --no-print-directory --just-print
例如（可能会更好）：
[aiden@host linux-2.6.29.2]$ \
make > build_out.txt; grep -o -E "[a-zA-Z0-9_-]+\.[ch]" build_out.txt
不完美，但以一种骇人听闻的方式为我工作，应该让你继续前进。相同的基本过程有望通过配置内核的盲目制作。
警告 在不维护特定于架构的工具链或在目标架构上运行 Make 的情况下，某些 ASM 和特定于架构的文件与真正的构建不同。
从评论中编辑
要抑制 ld 失败，您需要在内核 make 文件中找到以下部分（或类似部分）。
# Make variables (CC, etc...)
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
CC = $(CROSS_COMPILE)gcc
CPP = $(CC) -E
AR = $(CROSS_COMPILE)ar
您需要先运行配置步骤来配置源代码，然后再尝试枚举前面步骤中使用的源文件（从空运行中进行管道和 grepping），因此您可以在 Makefile.enum 中进行编辑并使用它在您运行正常的配置步骤之后（无论架构如何，都需要生成一些 config.h 类型的文件。因此，将内核源代码获取到您将要进行实际编译的地步，模块和所有）。呼！
现在，当您使用 fake-make 枚举源文件时，发布内核源配置（指定驱动程序/模块等）LD 将失败，正如您所发现的那样。您可以从
LD = $(CROSS_COMPILE)ld
到
LD = -$(CROSS_COMPILE)ld
注意“-”字符。这告诉 Makefile 忽略警告。显然，您尝试做的事情是不寻常的，但非常酷:) 可以通过查找 Makefile 部分并调整执行的命令来抑制进一步的错误。我建议您对 Makefiles 非常友好，因为您可能需要稍后更改 IF 语句。整理完所有内容后，您将拥有一个“哑”的 makefile，它将吐出 .c 文件，以便您可以做
make | grep -E "[a-zA-Z0-9_-]+\.[ch]"
或其他。
我还有一个很酷的建议来验证你的结果......实际构建内核......但使用 Linux 的 inotify API（你可以在此处获取 Python 绑定 http://pyinotify.sourceforge.net/）并在编译窗口中观察文件系统事件（例如 gcc 正在读取的 .c 文件）。然后将其与“哑”makefile 中的列表进行比较。
好的，我希望这不是华夫饼！ 祝你好运
【讨论】：