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" <ztur...@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 <vhar...@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 <ztur...@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 <chandl...@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@cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> >> >> -- >> >> Vince Harron | Technical Lead Manager | vhar...@google.com | 858-442-0868 >> > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
