As of this week, we have the test suite running clean under MSVC 2015 using Python 3.5. I’m sure new things will pop up, but I’m considering the transition “done” as of now.
What this means for MSVC 2013 is that we dont’ want to support it anymore.
Reasons:
C++ language support is poor
Compiling your own version of Python is difficult and a high barrier to entry for people wanting to build LLDB on Windows
LLVM will eventually bump its minimum MSVC version to 2015 as well.
This week I plan to update the build instructions on lldb.org to reflect the simpler more streamlined instructions for 2015 and remove the instructions for 2015.
I know some people are still using 2013. I don’t plan to break anything or explicitly remove support from CMake or anywhere else for 2013. I’m only saying that unless someone else steps up to keep this configuration working, it may break at any time, there won’t be a buildbot testing it, and I can’t guarantee anything about it continuing to work.
Note that when LLVM bumps its minimum required version to MSVC 2015 (expected this year), it will be very hard for anyone to continue using Python 2 on Windows at tip of trunk. The only real workaround for this is going to be forking Python (on your own end) and making whatever changes are necessary to Python to keep it compiling, as they will not accept the patches upstream.
We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for Android Studio and we also have a buildbot what is testing this configuration (without sending e-mail at the moment) here: http://lab.llvm.org:8011/builders/lldb-windows7-android
We are in the discussion to decide what is our plan for going forward both in terms of Visual Studio version and Python version and I expect that we will make a decision this week. Until then please don’t remove any hack we have in the code because of MSVC 2013 (e.g. alias template workarounds) and if adding new code then please try not to break MSVC 2013. I will send out an update about our decision hopefully at the end of this week.
You mentioned that LLVM plan to bump the minimum version of MSVC to 2015. Do you have any link to the place where they discussed it or do you know anything about the schedule?
We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for Android Studio and we also have a buildbot what is testing this configuration (without sending e-mail at the moment) here: http://lab.llvm.org:8011/builders/lldb-windows7-android
We are in the discussion to decide what is our plan for going forward both in terms of Visual Studio version and Python version and I expect that we will make a decision this week. Until then please don’t remove any hack we have in the code because of MSVC 2013 (e.g. alias template workarounds) and if adding new code then please try not to break MSVC 2013. I will send out an update about our decision hopefully at the end of this week.
Yea I mentioned already that I’m not planning on removing anything related to MSVC 2013, just that I’m personally not supporting it. Which means that if anyone asks for help, or wants to make it work, or if it breaks accidentally, they’re on their own I don’t even have MSVC 2013 installed on my machine anymore, so I can’t fix any MSVC 2013 specific issues that arise.
Of course if someone else comes along and wants to help, I have no problem with that, but due to the difficulty of dealing with incompatibility between Python 2 and MSVC 2015, it’s just going to be up to someone else to continue making that work if they need it.
You mentioned that LLVM plan to bump the minimum version of MSVC to 2015. Do you have any link to the place where they discussed it or do you know anything about the schedule?
As far as I know the discussion hasn’t started yet, but historically LLVM has always been pretty consistent about bumping the required MSVC version every 12-18 months. I know some of the Windows people on the LLVM side are already “unoficially” using MSVC 2015 on a regular basis, and that’s usually a sign that people are getting an early start to see what kind of issues might be encountered by the general public when bumping the required version.
If I remember correctly your bot isn’t actually doing anything differently than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015]. If you want you could just remove your bot. If you want to keep it, then yea getting it on VS2015 and Python 3 would be the best idea.
It’s Server 2008 R2 technically, which is the server version of Win 7 (same API set, same OS features, etc). So yea, I’m pretty confident that test coverage is going to be 100% the same across both. It’s just a matter of if you want to have something that you maintain / have control over, or if you want to test something in a different way than what we’re testing.
You may have to make some changes to the zorg scripts to keep that working. I didn’t realize there were any other bots building LLDB, so I made some changes that will default everything to VS2015 and Py3.
BTW, is your builder doing a debug build or a release build? When doing a debug build clang now requires more memory than can fit in a 4GB address space to link, so using an x86 toolchain won’t work anymore. I forced a change to use the amd64_x86 toolchain, but this won’t work unless the version of python used by buildbot is a 64-bit Python distro (because Python.exe is what ultimately calls vcvarsall and cmake and it inherits the environment of the parent).
BTW, I expect that your buildbot has been experiencing the problems with the x86 / x64 toolchain for quite some time, because it’s not really relevant to how much memory your machine has, but just that it was using an x86 toolchain at all. Has it been red for a long time?
we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter
problems there, the backup plan is to go to python 3 as well. Until
then (I estimate that will take 1--2 weeks) our buildbot
<http://lab.llvm.org:8011/builders/lldb-windows7-android> will
continue building 2.7+2013 and we will be making sure it works, so
please don't check in any VS2013 incompatible code (yet).
Ted: If you can't switch to the 3+2015 combination (which I *do*
recommend you try), maybe you can go half-way and switch to 2.7+2015
(I can show you how to build python 2.7 with VS2015). If you stick
with 2.7+2013 combo, it will soon be up to you to chase anyone who
adds 2013-breaking changes...
Out of curiosity, did you guys get Python 2.7 building with VS2015? How did you solve the compiler error? (I had a few ideas myself for how to fix it, but I wasn’t sure of the implications)
The timezone part seems pretty non-controversial. The _PyVerify_fd
thing seems more scary, but I basically copied that part out of
python3, so I assume they know what they are doing. With this I can
compile and run the python and it appears to be working. The real test
will be when I try to run the lldb test suite with it, but I didn't
set that up yet.
after overcoming some problems, mostly unrelated to MSVC, we have
finally managed to switch to VS2015. I think that means there are no
more VS2013 users remaining. Given that, shall we start the process to
formally allow c++ features, which were blocked due to VS2013 until
now? I am mostly thinking about thread-safe function-static variable
initialization and alias templates here...
At Codeplay we are currently building on windows using a split of MSVC 2013 and MSVC 2015.
In theory we are happy to move entirely to 2015, but until then we would have to work around any 2013 breakages.
Keep in mind that llvm bumps minimum vs version roughly once a year, and it’s probably about that time. So the discussion here is just about whether to do it earlier than llvm, not whether to do it all.
So whether it’s now or a few months from now, at some point you’re going to have to handle these incompatibilities in your own fork out of tree
We’re currently still using Python 2.7 and VS 2013 on the Qualcomm Hexagon team. We expect to keep pulling from upstream until about the middle of June, then branch for a release. We’d rather not switch to Python 3.5/VS 2105 for this release.
I don’t even have MSVC 2013 installed on my machine anymore, so I can’t fix any MSVC 2013 specific issues that arise.