[lldb-dev] Is anyone using the LLDB CMake standalone build?
badlogicgames at gmail.com
Mon Dec 29 14:05:52 PST 2014
FWIW, we use exactly the setup you outlined, for the reasons you mention:
CMake build to build LLDB and dependencies, XCode for debugging and code
editing. We are mostly concerned with Mac OS X/iOS but are also building
for Linux that way.
>From an API user perspective it's very nice to have a cross-platform build
that also integrates well with CI servers.
On Dec 29, 2014 10:13 PM, "Zachary Turner" <zturner at google.com> wrote:
> Someone jump in and correct me if I'm wrong, but I believe there are many
> reasons that Apple sticks with a hand-maintained Xcode project. I will try
> to summarize some of the reasons here:
> 1) People are more comfortable editing a native solution file than editing
> CMake. I certainly sympathize with this, as I also strongly prefer editing
> a Visual Studio solution over a CMake file. Before working on LLDB, I had
> actually never even written a line of CMake before.
> 2) The Xcode projects generated by CMake are slow, almost to the point of
> being unusable. This is a widespread problem with IDEs, and indeed the
> MSVC generator suffers from the same problem. The issue here is related to
> the size of the project / solutions. Every CMake target (which ultimately
> translates to a static library or shared library) ends up as a project in
> your solution (MSVC) or target in your project (Xcode). This is the layer
> at which dependency analysis is performed and build parallelization is
> implemented, so having more projects causes tremendous slowdown in loading
> projects/solutions and generating information for intellisense/code
> completion. Visual Studio has gotten much better in this regard with
> recent versions, but it's still an issue. And I think Xcode has *not* gotten
> much better in this regard. In short, an Xcode generated solution, while
> it will technically work, is almost unusable for performance reasons.
> 3) The Xcode projects generated by CMake aren't as pretty as
> hand-generated Xcode projects. It's actually possible to make prettier
> generated projects by adding some stuff to the CMake, but right now they
> just don't look as nice.
> 4) Legacy reasons (aka old habits die hard). The LLDB group at Apple has
> historically treated LLVM and clang as libraries, and in the past the only
> supported way to build LLDB was against a known revision of clang and LLVM,
> and only recently (well, not recent anymore, but legacy decisions can have
> long lasting implications) was it changed so that LLDB is expected to
> always build against tip of trunk LLVM / clang. One of the things that
> came out of this early separation was that an Xcode build of LLDB does not
> even use the canonical on-disk directory hierarchy that all other LLVM
> subprojects use. A normal LLVM directory layout looks like this:
> -- tools
> ---- lldb
> ---- clang
> ---- lld
> Since LLDB considers itself "not an LLVM subproject, but rather a
> standalone project which uses LLVM", it organizes itself like this:
> -- llvm
> ---- tools
> ------ clang
> ------ lld
> Of course, this is just an implementation detail, as we've shown that lldb
> can be built as a normal subproject on all other platforms using the first
> layout, but this basically boils down to "old habits die hard". It's what
> people are used to.
> It's certainly easy to sympathize with numbers 1, 3, and 4 but ultimately
> I think (or at least hope) that people would be willing to sacrifice these
> for the greater good of having a unified build system. Number 2 however,
> is probably a showstopper though.
> I'm not sure just how bad the Xcode solution is in terms of performance,
> but it's the primary reason why the the standalone build exists. The
> standalone build generates a much smaller project/solution, with only those
> projects and targets that are part of LLDB itself, and not projects from
> LLVM, clang, etc. It attempts to use an installed LLVM / clang instead of
> building one.
> One thing that has worked very well for me on Windows is using my IDE for
> editing and debugging, but not for building. There's quite a lot to like
> about this approach. For starters, the performance of building from inside
> the IDE is irrelevant now, because you're not building from the IDE
> anymore. For Visual Studio this makes a huge difference, but I'm not sure
> if it makes a difference for Xcode. Another advantage of this approach is
> that honestly, ninja is just faster than everything else. It really is.
> And not a little bit, but a lot. I'm a big fan of my IDE and you will only
> pry it out of my cold dead hands, but after I tried ninja once or twice, it
> was obvious that it was a huge win over building from the IDE. All it
> takes me is typing "ninja" from a command shell. Even I can manage that.
> Everything else - debugging, code completion, editing experience, file
> browsing - still works. I just don't hit build from inside the IDE.
> It would be worth seeing if an approach like this would work well with
> people from Apple. Or alternatively, maybe seeing if the Xcode IDE team
> within apple would be willing to prioritize IDE performance in the case of
> these larger projects. Visual Studio seems to have come a long way here,
> so it doesn't seem impossible for Xcode to improve here, it just has some
> work to do.
> On Mon Dec 29 2014 at 12:25:20 PM Vince Harron <vharron at google.com> wrote:
>> > The main motivation for having a standalone build is that it's a
>> necessary (but not necessarily sufficient) precursor to having a usable
>> xcode solution, which is itself a necessary (but again perhaps not
>> sufficient) precondition to moving towards a single build system.
>> I've always assumed that the reason the apple guys don't generate their
>> xcode projects from cmake is that there is some magic in the xcode projects
>> that isn't supported by cmake-xcode project generator. Is there any truth
>> to that?
>> What is the intended purpose of the LLDB CMake standalone build? If it
>> is to build against an installed clang/llvm, it doesn't seem like it's
>> worth the extra complexity...
>> On Sun, Dec 28, 2014 at 9:15 AM, Zachary Turner <zturner at google.com>
>>> I'm not using the standalone build on Windows, i just suffer through
>>> opening a mega solution. Reid did some work recently to make it better, but
>>> it still doesn't totally support anyone's needs.
>>> The main motivation for having a standalone build is that it's a
>>> necessary (but not necessarily sufficient) precursor to having a usable
>>> xcode solution, which is itself a necessary (but again perhaps not
>>> sufficient) precondition to moving towards a single build system.
>>> I'm not versed enough in the LLVM core shared CMake infrastructure, but
>>> I envision a world where supporting a standalone build requires almost 0
>>> project specific CMake code. Sadly, achieving that seems quite difficult
>>> On Sun, Dec 28, 2014 at 7:22 AM Chandler Carruth <chandlerc at gmail.com>
>>>> I thought that Zach was on Windows, but I would be surprised as I can't
>>>> get it to work with an installed Clang. It errors in the cmake step, unable
>>>> to find some cmake module.
>>>> Is anyone genuinely trying to support this CMake configuration? It adds
>>>> quite a bit of complexity. If so, could they fix this error or suggest how
>>>> to fix it on the Clang side? (I help maintain the Clang cmake build, so I'm
>>>> happy to enact any reasonable changes needed...)
>>>> This came up because I have a change to the LLDB CMake build but am
>>>> currently unable to test it in a fully standalone build (IE, w/o a source
>>>> lldb-dev mailing list
>>>> lldb-dev at cs.uiuc.edu
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>> Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev