Question

当将两个相对较远的Linux内核源代码树平分时提交，前几个二分步骤通常会改变很多内核源代码，因此无论make distclean是否运行，都不会成为一个大问题区别。但是，随着二分范围越来越窄，源文件越来越少在每一步都被更改，因此清理源树将删除很多 <{1}}不需要重建的文件。

由于*.o通过比较它们来推断需要重建的目标文件最后修改时间到他们相关的源文件，我想在每次二分步骤之后没有必要清理树，但我确实如此无论如何，作为预防措施，我遇到了一个漫长的情况二分过程让我最终陷入了一个无关的“坏”提交有问题的bug。

为了使其具体化，这是我在第一次二分尝试中使用的步骤（这让我错误的提交）：

make

我使用以下程序再次分成两次，并且能够成功达到错误的提交：

cp /boot/config-`uname -r` .config
make oldconfig
make && sudo make modules_install && sudo make install
# reboot
# Then I repeat the following steps until the bisection ends.
# test the kernel
git bisect {good,bad}
make && sudo make modules_install && sudo make install
# reboot

因为我不太了解kenrel构建系统的内部，所以如果有人能以某种方式指出我可以避免的话会很棒因此，在每个二分步之后清理并重建整个内核这将节省我很多的构建时间，并将缩短二分过程相当。

Answer 1

从 the man

make程序使用makefile数据库和最后修改时间这些文件决定了哪些文件需要更新。

和快速实验

$ stat -c%y bar.txt
2013-05-11 22:58:46.499826200 -0500

$ git checkout HEAD~1
HEAD is now at e7b9f1c... first

$ stat -c%y bar.txt
2013-05-11 22:58:52.583836900 -0500

如您所见，执行checkout会更改修改时间文件，反过来会强制它与make重新编译。所以答案是的，没有必要清理树，因为必要的文件将是重新编译。

是否有必要在每次二分步后清理Linux内核源代码树？

1 个答案: