[lldb-dev] Is anyone using the LLDB CMake standalone build?

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:
>
> llvm
> -- 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:
>
> lldb
> -- 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...
>>
>> Vince
>>
>>
>> On Sun, Dec 28, 2014 at 9:15 AM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> 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>
>>> wrote:
>>>
>>>> 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
>>>> tree).
>>>>
>>>> -Chandler
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>>
>> Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141229/82a24328/attachment.html>