What kind of problems? ninja is the only thing I've used for the past 6 months and I've never had an issue. Granted I did have many issues in the beginning, but I'm not sure if they were ninja specific so much as just issues with LLDB not having been well supported on Windows.<br><div><br></div><div>I would encourange you to give it a try again. If you still have issues, make a new thread about it so we don't derail this one. But I'm definitely curious to hear about your experience now.</div><div><br></div><div>The primary speed benefit from ninja comes from incremental builds, but clean ninja builds should still be faster than clean MSBuild builds as well.</div><br><div class="gmail_quote">On Tue Dec 30 2014 at 8:36:33 AM Colin Riley <<a href="mailto:colin@codeplay.com">colin@codeplay.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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.</div></div><div text="#000000" bgcolor="#FFFFFF"><div><br>
<br>
On 29/12/2014 22:22, Zachary Turner wrote:<br>
</div></div><div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">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.<br>
<br>
<div class="gmail_quote">On Mon Dec 29 2014 at 2:19:21 PM Ted
Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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).</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We
package a full toolset (clang, llvm tools, lldb)
together, so our lldb builds compile everything from
source.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm
Innovation Center, Inc.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The
Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, a Linux Foundation Collaborative Project</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <a href="mailto:lldb-dev-bounces@cs.uiuc.edu" target="_blank">lldb-dev-bounces@cs.uiuc.edu</a>
[mailto:<a href="mailto:lldb-dev-bounces@cs.uiuc.edu" target="_blank">lldb-dev-bounces@cs.uiuc.edu</a>] <b>On
Behalf Of </b>Mario Zechner<br>
<b>Sent:</b> Monday, December 29, 2014 4:06 PM<br>
<b>To:</b> Zachary Turner<br>
<b>Cc:</b> LLDB Development Mailing List; Chandler
Carruth<br>
<b>Subject:</b> Re: [lldb-dev] Is anyone using the
LLDB CMake standalone build?</span></p>
</div>
</div>
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"> </p>
<p>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.</p>
<p>From an API user perspective it's very nice to have a
cross-platform build that also integrates well with CI
servers.</p>
<div>
<p class="MsoNormal">On Dec 29, 2014 10:13 PM, "Zachary
Turner" <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>>
wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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:<br>
<br>
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.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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 <b>not</b> gotten
much better in this regard. In short, an Xcode
generated solution, while it will technically
work, is almost unusable for performance reasons.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">llvm</p>
</div>
<div>
<p class="MsoNormal">-- tools</p>
</div>
<div>
<p class="MsoNormal">---- lldb</p>
</div>
<div>
<p class="MsoNormal">---- clang</p>
</div>
<div>
<p class="MsoNormal">---- lld</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Since LLDB considers itself
"not an LLVM subproject, but rather a standalone
project which uses LLVM", it organizes itself like
this:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">lldb</p>
</div>
<div>
<p class="MsoNormal">-- llvm</p>
</div>
<div>
<p class="MsoNormal">---- tools</p>
</div>
<div>
<p class="MsoNormal">------ clang</p>
</div>
<div>
<p class="MsoNormal">------ lld</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Mon Dec 29 2014 at 12:25:20
PM Vince Harron <<a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a>>
wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">> <span style="font-size:10.0pt">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.</span></p>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">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?</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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...</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Vince</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Sun, Dec 28, 2014 at
9:15 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>>
wrote:</p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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. <br>
<br>
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.<br>
<br>
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 </p>
<div>
<div>
<div>
<p class="MsoNormal">On Sun, Dec 28,
2014 at 7:22 AM Chandler Carruth
<<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>
wrote:</p>
</div>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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...)</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">-Chandler</p>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal">-- </p>
<div>
<div>
<p class="MsoNormal"> </p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="border:none;border-top:solid #d50f25 1.5pt;padding:0in 0in 0in 0in" nowrap>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#555555">Vince
Harron |</span></p>
</td>
<td style="border:none;border-top:solid #3369e8 1.5pt;padding:0in 0in 0in 0in" nowrap>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#555555"> Technical
Lead Manager |</span></p>
</td>
<td style="border:none;border-top:solid #009939 1.5pt;padding:0in 0in 0in 0in" nowrap>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#555555"> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</span></p>
</td>
<td style="border:none;border-top:solid #eeb211 1.5pt;padding:0in 0in 0in 0in" nowrap>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:#555555"> <a href="tel:858-442-0868" target="_blank">858-442-0868</a></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
lldb-dev mailing list
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
</blockquote>
<br>
</div>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>