[lldb-dev] Circular library dependencies

[Greg Clayton]

> On Mar 17, 2015, at 11:25 AM, Zachary Turner <zturner at google.com> wrote:
> 
> 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.
> 
> 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.  
> 
> 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.
> 
> Basically what I found is that every folder more or less depends on every other folder, which is pretty unfortunate.
> 
> 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.
> 
> Thoughts?

On MacOSX the linking process is quick, I am not sure how fast linking is on other platforms. 

I really want the code organized by functionality not optimized for linking. Everything in LLDB links against just about everything else and there should be no limits imposed on what can link with what.

Linking static libraries is only for tools that want to use the dangerous internals of LLDB. Really most tools should link against our public API. I know that lldb-server is one of the tools that needs the internals and it should stay that way. 

I would rather not see any changes/reorganization going on to optimize linking unless it makes a lot of sense organizationally and I think we have decent organization in our source tree. 

Greg