[PATCH] Create an experimental Windows LLDB Builder

[Rick Foos]

================
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()
----------------
zturner wrote:
> 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?
buildbotic vs. pythonic :)
I'm OK with it as long as the subprocess is running on the buildslave. I had thought that code like that was running on the buildmaster.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:45
@@ +44,3 @@
+            target_arch='x86',
+
+            extra_cmake_args=[]):
----------------
zturner wrote:
> zturner wrote:
> > 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.
> Read this for information about why LLDB requires a custom built version of Python
> 
> http://lldb.llvm.org/build.html#BuildingLldbOnWindows
> 
> One reason I'm fond of the solution I've got here is because both the python source dir and the MSVC dir are configurable, so it's future proof against MSVC versions and should easily handle the case of specifying a 64-bit python.  Just build 32 and 64-bit pythons from different source trees, and pass a different value for the python source dir.
Currently I'm building with a standard python release, and running with a pre-built MSVC2013 python.

We were doing fairly well without it, but when LLDB is a debug version, the python also has to be a debug version and none of the released pythons are built for debug.

changing the slave_envCmd from the builder is all you have to do to switch things as well, but the slave_envCmd also works for Linux r"""printenv""" which was one of my goals in a Windows/Linux build factory.

http://reviews.llvm.org/D6745

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