> On Mar 17, 2015, at 1:39 PM, Zachary Turner <[email protected]> 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
