<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Institutional inertia? </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I’m not sure – I’m not on the build team – but I’ll forward your suggestion on to them.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>--<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Qualcomm Innovation Center, Inc.<o:p></o:p></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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></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'> Zachary Turner [mailto:zturner@google.com] <br><b>Sent:</b> Monday, December 29, 2014 4:23 PM<br><b>To:</b> Ted Woodward; Mario Zechner<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?<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p><div><p class=MsoNormal>On Mon Dec 29 2014 at 2:19:21 PM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org">ted.woodward@codeaurora.org</a>> wrote:<o:p></o:p></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><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>--</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Qualcomm Innovation Center, Inc.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></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.<o:p></o:p></p><p>From an API user perspective it's very nice to have a cross-platform build that also integrates well with CI servers.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Dec 29, 2014 10:13 PM, "Zachary Turner" <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>llvm<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-- tools<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---- lldb<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---- clang<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---- lld<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Since LLDB considers itself "not an LLVM subproject, but rather a standalone project which uses LLVM", it organizes itself like this:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>lldb<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-- llvm<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---- tools<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>------ clang<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>------ lld<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> <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><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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...<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>Vince</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sun, Dec 28, 2014 at 9:15 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 <o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sun, Dec 28, 2014 at 7:22 AM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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...)<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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).<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-Chandler<o:p></o:p></p></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<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><o:p></o:p></p></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;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><o:p></o:p></p></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-- <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0><tr><td nowrap style='border:none;border-top:solid #D50F25 1.5pt;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Arial",sans-serif;color:#555555'>Vince Harron |</span><o:p></o:p></p></td><td nowrap style='border:none;border-top:solid #3369E8 1.5pt;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Arial",sans-serif;color:#555555'> Technical Lead Manager |</span><o:p></o:p></p></td><td nowrap style='border:none;border-top:solid #009939 1.5pt;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Arial",sans-serif;color:#555555'> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</span><o:p></o:p></p></td><td nowrap style='border:none;border-top:solid #EEB211 1.5pt;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Arial",sans-serif;color:#555555'> <a href="tel:858-442-0868" target="_blank">858-442-0868</a></span><o:p></o:p></p></td></tr></table><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;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><o:p></o:p></p></blockquote></div></div></div></blockquote></div></div></body></html>