平湖公司做网站,网站建设hairongsoft,模板网站对排名的影响,网站怎么上传源码博主参与了一个使用qmake构建的项目#xff0c;包含几百个源文件#xff0c;最近遇到一个恼人的问题#xff1a;有时仅仅修改了一个.cpp文件#xff0c;构建项目时就有可能触发全编译。但是编译时又会命中ccache的缓存#xff0c;这说明源代码实际上内容并没有发生变化。即…博主参与了一个使用qmake构建的项目包含几百个源文件最近遇到一个恼人的问题有时仅仅修改了一个.cpp文件构建项目时就有可能触发全编译。但是编译时又会命中ccache的缓存这说明源代码实际上内容并没有发生变化。即使命中了ccache缓存几百个源文件编译下来还是要耗一小会儿时间的博主对此不能熟视无睹。
本文中使用了一个demo项目stupid_qmake来复现和分析该问题其结构非常简单
stupid_qmake/
├── main.cpp
├── stupid_qmake.pro
└── utility├── foo.cpp└── foo.hmain.cpp文件内容如下调用了std::swap以及标准输出流
#include iostream
#include utilityint main() {int a 1;int b 2;std::swap(a, b);std::cout a b std::endl;return 0;
}正常来说如果我们修改了一个.h文件那么所有依赖这个.h文件的.cpp文件都需要重新编译无论是直接include还是间接include而修改一个.cpp文件则重新编译这个.cpp就足够了。
这些重新编译的触发依赖于构建系统以下面的Makefile为例
CXX g
CXXFLAGS -Wall -g
TARGET my_programSRCS main.cpp func.cpp
OBJS main.o func.oall: $(TARGET)$(TARGET): $(OBJS)$(CXX) $(CXXFLAGS) -o $ $^main.o: main.cpp func.h$(CXX) $(CXXFLAGS) -c main.cpp -o main.ofunc.o: func.cpp func.h$(CXX) $(CXXFLAGS) -c func.cpp -o func.oclean:rm -f $(OBJS) $(TARGET).PHONY: all clean不算伪目标共有3个targetmy_program、main.o和func.o。target和target之间的依赖以及target对源文件的依赖如下图所示 #mermaid-svg-QVJZDQHtxEJcaK6N {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .error-icon{fill:#552222;}#mermaid-svg-QVJZDQHtxEJcaK6N .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-QVJZDQHtxEJcaK6N .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-QVJZDQHtxEJcaK6N .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-QVJZDQHtxEJcaK6N .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-QVJZDQHtxEJcaK6N .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-QVJZDQHtxEJcaK6N .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-QVJZDQHtxEJcaK6N .marker{fill:#333333;stroke:#333333;}#mermaid-svg-QVJZDQHtxEJcaK6N .marker.cross{stroke:#333333;}#mermaid-svg-QVJZDQHtxEJcaK6N svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-QVJZDQHtxEJcaK6N .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .cluster-label text{fill:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .cluster-label span{color:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .label text,#mermaid-svg-QVJZDQHtxEJcaK6N span{fill:#333;color:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .node rect,#mermaid-svg-QVJZDQHtxEJcaK6N .node circle,#mermaid-svg-QVJZDQHtxEJcaK6N .node ellipse,#mermaid-svg-QVJZDQHtxEJcaK6N .node polygon,#mermaid-svg-QVJZDQHtxEJcaK6N .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-QVJZDQHtxEJcaK6N .node .label{text-align:center;}#mermaid-svg-QVJZDQHtxEJcaK6N .node.clickable{cursor:pointer;}#mermaid-svg-QVJZDQHtxEJcaK6N .arrowheadPath{fill:#333333;}#mermaid-svg-QVJZDQHtxEJcaK6N .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-QVJZDQHtxEJcaK6N .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-QVJZDQHtxEJcaK6N .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-QVJZDQHtxEJcaK6N .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-QVJZDQHtxEJcaK6N .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-QVJZDQHtxEJcaK6N .cluster text{fill:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N .cluster span{color:#333;}#mermaid-svg-QVJZDQHtxEJcaK6N div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-QVJZDQHtxEJcaK6N :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} my_program main.o func.o main.cpp func.h func.cpp 在执行make时make不会也不可能真的去检查源文件内容是否发生了变化而是会根据源文件和target的最后修改时间mtime以及target之间的依赖关系来决定哪些target需要重新生成如果源文件的mtime比target的mtime大说明源文件有更新这个target需要重新生成同时所有依赖这个target的其他target也需要重新生成。
在我们的demo项目中从main.cpp的内容来看修改foo.h/foo.cpp不应当导致main.cpp重新编译但实际情况并非如此每当使用qtcreator编辑foo.cpp后总会触发main.cpp的重新编译。
这个问题分析起来的入手点就是看看qmake到底为我们生成了一个怎样的Makefile —— 如果你在命令行中编译过qmake项目你应该知道运行qmake命令时会在构建目录中生成一个Makefile文件然后再运行make命令才会正式开始项目的编译。
stupid_qmake.pro文件生成的Makefile中main.o和foo.o两个target的生成规则如下
main.o: ../main.cpp ../utility$(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../main.cppfoo.o: ../utility/foo.cpp ../utility/foo.h$(CXX) -c $(CXXFLAGS) $(INCPATH) -o foo.o ../utility/foo.cppfoo.o的生成规则没什么问题main.o的生成规则看起来有点奇怪在依赖项中竟然有一个utility目录。它为什么会在依赖项中呢联想到main.cpp源文件中依赖了utility头文件我们可以猜测qmake在生成依赖规则时utility目录被错误地视为了utility头文件被添加到了main.cpp的依赖项中。为了验证这个猜测我们把main.cpp中对utility头文件的依赖去掉然后重新运行qmakemain.cpp的生成规则就变成了
main.o: ../main.cpp $(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../main.cpp没有那条对utility目录的依赖了所以我们的推测是正确的是qmake混淆了utility目录和utility头文件。
依赖项列表中有一项是目录会产生什么后果呢make似乎并不介意这件事仍然会机械地扫描依赖项的mtime以此决定哪些target需要重新生成。所以现在需要探讨的问题是目录的mtime在什么情况下会更新关于这个问题我在另外一篇博客Linux使用vim编辑文件为什么会影响目录的mtime中分析过在那篇博客中我是以vim为例来分析的实际上qtcreator也有相同的效果当你使用qtcreator编辑了某个目录下的文件后这个目录的mtime就会更新。所以说在我们的demo项目中如果你编辑了utility目录下的文件utility目录的mtime就会更新进而引起main.cpp的重新编译。
回到博文开头提到的那个项目里面恰好有一个utility目录而且这个目录下的源文件的修改也比较频繁。那么现在我们可以还原出整个问题的全貌C标准库中的utility头文件是一个被广泛包含的头文件整个项目中的大部分源文件都对它有直接或者间接的依赖。而qmake错误地将项目中一个名为utility的目录当成了utility头文件这件事就会导致utility目录被添加到了大部分.o文件的依赖项中。一旦我们编辑了utility目录下的文件utility目录的mtime就会被更新这将会导致大部分源文件重新编译。
问题修改起来也简单在将utility目录重命名为util后恼人的问题就消失了。
按理说遇到这种情况时qmake应当优先匹配系统目录下的头文件有时间了研究一下qmake的源码看看它为什么没有这么做
