[lldb-dev] Is anyone using the LLDB CMake standalone build?
Colin Riley
colin at codeplay.com
Tue Dec 30 08:35:41 PST 2014
Is that true now? The last time I tried ninja on windows (months ago) to
full rebuild LLDB/llvm/clang it was not significantly faster and had
lots of problems with the tablegen steps.
On 29/12/2014 22:22, Zachary Turner wrote:
> Just curious - why not ninja on Windows? As long as you run vcvars
> beforehand (which you have to use anyway even for an MSBuild build)
> the output is going to be identical to that which is produced by
> MSBuild, but it will be faster.
>
> On Mon Dec 29 2014 at 2:19:21 PM Ted Woodward
> <ted.woodward at codeaurora.org <mailto:ted.woodward at codeaurora.org>> wrote:
>
> We use the "normal" LLVM layout mentioned below. We use cmake on
> 64 bit Linux and Windows to set up our build environment, the
> build with make on Linux and msbuild on Windows (although, on my
> Windows box I open the solution in VS).
>
> We package a full toolset (clang, llvm tools, lldb) together, so
> our lldb builds compile everything from source.
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora
> Forum, a Linux Foundation Collaborative Project
>
> *From:*lldb-dev-bounces at cs.uiuc.edu
> <mailto:lldb-dev-bounces at cs.uiuc.edu>
> [mailto:lldb-dev-bounces at cs.uiuc.edu
> <mailto:lldb-dev-bounces at cs.uiuc.edu>] *On Behalf Of *Mario Zechner
> *Sent:* Monday, December 29, 2014 4:06 PM
> *To:* Zachary Turner
> *Cc:* LLDB Development Mailing List; Chandler Carruth
> *Subject:* Re: [lldb-dev] Is anyone using the LLDB CMake
> standalone build?
>
> 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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:lldb-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
> --
>
> Vince Harron |
>
>
>
> Technical Lead Manager |
>
>
>
> vharron at google.com <mailto:vharron at google.com> |
>
>
>
> 858-442-0868 <tel:858-442-0868>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141230/6af78c97/attachment.html>
More information about the lldb-dev
mailing list