[lldb-dev] Circular library dependencies

[Zachary Turner]

Sadly DLLs don't work quite the same on windows as they do on other
platforms. On Windows a symbol is not exported unless you specifically tag
the symbol with a compiler attribute. So being able to use a class this way
from a test would require exporting it and everything it exposes from its
public interface, so it will quickly grow out of control tagging every
function and class this way. See the class definitions on the public API
for examples of where we do this.

Another option is to make one unit test executable so at least we don't
have to pay for the link multiple times. That seems like the best
compromise if we can't figure out a better idea.
On Tue, Mar 17, 2015 at 1:58 PM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Mar 17, 2015, at 1:39 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I agree that it should be organized by functionality, but I think it's
> possible to organize it by functionality in a way that better linking falls
> out naturally as a consequence.  Also I'm not really talking about a major
> restructuring of every project, but just hitting a few key points.  A good
> example is how source/lldb has 2 random cpp files dropped in, lldb-log.cpp
> and lldb.cpp.  The way the CMake build works is that we treat all source
> files in a particular directory (and sometimes in sub-directories) as
> belonging to the same target, and each target is compiled to a .a file (or
> .lib file on Windows).  So source/lldb.cpp and source/lldb-log.cpp get put
> into something I've called lldbBase.a / .lib.  Now, since *everything* in
> the codebase depends on logging, we have to link everything against
> lldbBase, which also means lldb.o.  And lldb.o depends on pretty much
> everything in the entire project.
>
> Yes, this kind of change to better serve make/cmake is fine.
>
> > The way this came up in context is that our unit test runner builds
> multiple executables, one for each component being tested.  This makes the
> link time scale really horribly, because it's having to look at every .lib
> in all of LLDB just to link against one class.
>
> You could make a DLL that contains all of the LLDB internals so that you
> don't have to relink stuff over and over again.
>
> >
> > In any case, the organization also doesn't make much sense.  You can't
> use either source/lldb-log.cpp or source/Core/Log.cpp without the other, so
> seems to me they should both be in source/Core.
>
> Again, this kind of change is fine.
>
> > and lldb.cpp is kind of its own thing that is only necessary for global
> LLDB initialization, so it could be off by itself in like source/Initialize
> or something.
>
> Fine with that too.
>
> > So that's one example of something I wanted to fix.  So to sum up, I
> agree we shouldn't do anything that's purely an optimization and has no
> benefit to code organization, but I think there's some places where the
> organization could improve and the rest would happen naturally.
>
> I agree. But I would try and fix your rest runner to build against an
> lldb-internal.dll so you don't have to statically link tons of binaries
> over and over and pay a large cost, just make sure we don't expose the
> lldb-internal.dll to the outside world. We don't want people shipping tools
> that link against our internal C++ APIs, but is is quite OK for internal
> tests.
>
> Greg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150318/c9690b1c/attachment.html>