[PATCH] Create an experimental Windows LLDB Builder

[Zachary Turner]

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:14
@@ +13,3 @@
+def generateVisualStudioEnvironment(vs_install_dir, target_arch):
+    arch_arg = {'x86': 'x86', 'x64': 'amd64', 'amd64': 'amd64'}.get(target_arch, None)
+    if arch_arg is None:
----------------
rfoos wrote:
> I think these are intended to define a 32 or 64 bit host executable for X86 or ARM.
> 
> They not to define an LLVM cross compiler target arch (i.e. AARCH64, Hexagon...)
> 
> To match the build host, vcvarsall %PROCESSOR_ARCHITECTURE%
For the above 2 cases, it's talking about both the host AND the target.  In other words:

"vcvarsall x86" will use a 32-bit toolchain that produces 32-bit target executables
"vcvarsall amd64" will use a 64-bit toolchain that produces 64-bit target executables.

There are actually more values you can specify for the first argument to vcvarsall for cross compilation, but I'm not supporting those here.

I provided this argument because this way we can (later) provide slaves for both x86 and x64 on the same physical builder.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:21
@@ +20,3 @@
+    process = subprocess.Popen(vcvars_command, shell = True, stdout=subprocess.PIPE, stderr = None)
+    (stdout, _) = process.communicate()
+    vars = stdout.splitlines()
----------------
rfoos wrote:
> Why not use buildbot's SetProperty? It has a facility for returning stdout. This seems like more work to support.
I guess because I don't know how it works.  Isn't this the standard pythonic way to do this though?

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:45
@@ +44,3 @@
+            target_arch='x86',
+
+            extra_cmake_args=[]):
----------------
rfoos wrote:
> gkistanova wrote:
> > 3. Maybe add an optional env param here and support optional env property propagated from a slave and builder definitions to merge with the envs you are requesting from the slave?
> > 
> > In some cases it might be needed to define something in addition.
> > 
> > Not a how stopper and could wait till someone would really need the feature. Just be nice to have it.
> I'm suggesting a generic way to invoke VCVARSALL.BAT that works on any buildslave. 
> 
> This is for a 64 bit MSVC build, using a 64 bit version of Python.
> slavenvCmd=r"""PATH=C:\Python2764;C:\Python2764\Scripts;%PATH% & "%VS120COMNTOOLS%\..\..\VC\vcvarsall.bat" amd64 & set""",
> 
> (As part of this, I have to admit that I don't have a generic method for identifying a 64 bit python needed for 64 bit builds of LLDB)
> 
> 
> If you have multiple MSVC installations, these variables provide a reliable index to vcvarsall.bat. The locations are installation dependant, and the values can be different for each buildslave.
> 
> VS100COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools
> \
> VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools
> \
> VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools
> \
> ATM, MSVC 2013 is all that works. As it was in the past, MSVC 2014/2015 will become an option soon.
> 
> 
> 
> side note, VSINSTALLDIR isn't defined until after vcvarsall is run and a specific version selected.
> 
> 
I don't want to put Python in the path because LLDB requires linking against a manually compiled python, and I don't want anything to get confused.  Also if we ever make a builder with a new version of MSVC (say 2015), you would have to change this.  It seems like the way I've done it is sufficient, you just supply it a path to any version of MSVC, where it defaults to MSVC 2013, and it just works.

http://reviews.llvm.org/D6745

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/