<div dir="ltr">Trying to look at ways to reduce the link time of LLDB, I wrote a small python script last night whose purpose is to get a rough idea of what LLDB's dependency graph looks like.  A lot of this is CMake specific, but the idea isn't much different either way.<div><br></div><div>It does this by walking the source and incldue folder.  For each folder entered, it determines what .a this compiles to by looking for the corresponding CMakeLists.txt and doing a rudimentary parse.  </div><div><br></div><div>Then, for each .cpp and .h file found, scan the file for #include statements, and map the include file to the corresponding location under the source tree, using this to determine which .a file the #include is a primary member of.  For each of these found, add that .a file to the list of dependencies for the containing .a.</div><div><br></div><div>Basically what I found is that every folder more or less depends on every other folder, which is pretty unfortunate.</div><div><br></div><div>I have some ideas about how to make some improvements, but I want to see what people think first.  Aside from the obvious benefits of just making the code be better layered and more separable, it also would reduce link times quite a bit I think.  And there are lots of cases such as lldb-server or unit tests where we want to link in as little as possible, as opposed to the monolithic LLDB executable which wants to link in pretty much everything.</div><div><br></div><div>Thoughts?</div></div>