[PATCH] Create an experimental Windows LLDB Builder

Rick Foos rfoos at codeaurora.org
Wed Jan 7 15:37:43 PST 2015


================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:45
@@ +44,3 @@
+            target_arch='x86',
+
+            extra_cmake_args=[]):
----------------
zturner wrote:
> rfoos wrote:
> > 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.
> Not sure what you mean about building vs. running.  LLDB embeds python, and then links against itself via an extension module, so whatever you build with is also what you run with.  The extension module must be compiled with the same version of MSVC as the version of Python that LLDB links against.
> 
> AFAIK there is nothing special about Debug / Release here.  I used to think there was, but then I found out that the same issue is present for Release.  So you always need to compile python, regardless of whether it's a debug or release build of LLDB.
You are right. Somebody else stashed an MSVC2013 python and I missed it. We are linking against a 32 or 64 bit version of MSVC2013 python.

So we don't need to compile python on each build, but once for each build config matching the lldb build config.

http://reviews.llvm.org/D6745

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






More information about the llvm-commits mailing list