Poll: Minimum required MSVC version?

[johnkslang]

What should be the minimum version of MSVC required for glslang?

I'd been setting the bar at 2012 to be conservative across a broad base, but many submissions require 2013, which I then fix to work on 2012. (2012 supports a broad set of C++11, but not all those supported by 2013.)

Any input on a required minimum version?

[xorgy]

Unreal Engine 4 seems to set the bar at 2013. I wonder if that's a decent benchmark for industry acceptance, interested to see what others think.

[baldurk]

The project I embed glslang in uses 2010, and at least at the moment the subset of the glslang repo that I compile works there. I'm well aware that this is a minority opinion, but consider that one vote for keeping the bar as low as possible.

[xorgy]

Yeah, that's the other thing: even if the majority of people would be fine with 2013 (not saying this is the case, it can be pricey if you don't make a living on it), they're not excluded when we lower the bar, but others are when we raise it.

It's a shame Microsoft doesn't offer their compilers for free, that would fix everything. Can't very well tell everyone to build with mingw.

All of this said, one option would be to offer library binaries that could be linked by older versions of MSVC; That way we could require a later version for actual development(or you could develop on a platform where good free compilers are standard).
That doesn't sound completely great for version-locked Windows developers, though. Not sure how we could avoid alienating people who want to use fancier C++ features, while also welcoming the unfortunate souls stuck on MSVC 2010.

[baldurk]

In case anyone finds this issue through searching/browsing and also prefers to use VS2010, for now I'm maintaining a branch here that compiles on VS2010. Hopefully I'll be able to keep it as a minimal changeset 😄.

[mknejp]

Since VS2015 is out by now you might want to check the Community edition, which is for free for small teams (up to 5 people, check the license for details). Furthermore, as showed at CppCon this year they want to make Clang a fully integrated frontend for Windows development in the next update. They call it clang/c2, which means we'd have a Microsoft supported and fully C++14 compliant compiler for Windows integrated into VS2015.

Unless you aren't eligible for the Community version there is no real reason not to upgrade to VS2015 (and if you aren't you probably can afford Professional anyway). With the clang/c2 update virtually all platforms will have full C++14 support, which could do wonders to glslang's implementation and interface.

[xorgy]

@mknejp Not really sure that can afford translates to should budget, though VS2015 looks like it'll be a pretty long-term release, so long as they make it possible to update the clang toolchain separately from VS itself.

Assuming VC++2015 binaries are ABI compatible with other versions (I'm not really sure if that's true), you could probably build a static glslang and link it in an application in VS2010. As long as 5 or fewer people are working on the glslang library proper, or your contributions are all upstreamable and public (satisfying the open source clause).

[mknejp]

Speaking of the devil: Visual C++ Build Tools 2015 – standalone C++ tools
The qeustion now remains whether one can make the toolchain work with older VS versions.

[rdb]

Given how few changes it took me to make it compile with MSVC 2010 (see #175), I don't see the cost of maintaining MSVC 2010 portability to be very high.

Our engine still has to maintain MSVC 2010 support for various parties (partly because it's the last compiler to support targeting Windows XP) - if it was a matter of "just upgrade" we would have already done it.

[johnkslang]

Closing this out. We are being relatively successful at keeping 2010 working, and continue until that's deemed too burdensome.

[johnkslang]

Reopening. Anyone see any reasons to not move to VS 2015 at some point in the near(ish) future? I would agree 2017 is too soon, but hoping 2015 is okay.

From @baldurk in PR #761:

I'm planning to go all the way up to VS2015. In theory I could maybe get away with moving to say VS2013 currently, but there's not much point in doing a half-way step like that as it just means I need to repeat the process that much sooner if Qt drops 2013 in a year or whatever.

I'm not going up to VS2017 since it's just come out and not everyone will have it, but I think it's safe to assume by now that hobbyists and professionals will have 2015, and I don't need bleeding edge standards support from 2017.

[johnkslang]

Been a while.

I'd like fresh input on whether we could move to MSVS 2015 as the base.

[dneto0]

I'd be happiest with VS 2017. But VS 2015 is ok. SPIRV-Tools now requires VS 2015.
I would be ok with an older VS when ENABLE_OPT is disabled.

[greg-lunarg]

A few months ago LunarG attempted to drop VS2013 and move to VS2015 and got push back from CTS. LunarG relented. I don't mean to speak for CTS, but hoping to accelerate the discussion by suggesting we query CTS folks directly. I believe CTS uses both glslang and SPIRV-Tools.

[dgkoch]

Why is there such a pressing need to drop VS2013?

[greg-lunarg]

Why is there such a pressing need to drop VS2013?

In short, glslang uses SPIRV-Tools to "legalize" HLSL shaders. SPIRV-Tools uses googletest. googletest recently dropped support of VS2013.

[dneto0]

SPIRV-Tools uses googletest. googletest recently dropped support of VS2013.

I had mis-spoken earlier. SPIRV-Tools uses Effcee for newer tests, Effcee uses RE2 and RE2 dropped VS2013 support in December 2017.
So SPIRV-Tools stopped bot testing with VS2013, and some of its optimizer algorithms now have code that VS2013 fails to compile.

[nsubtil]

Dropping support for VS2013 seems premature. I know of several ISVs in the gaming industry that are still using VS2013 --- in fact, all engine code bases I've worked with recently either required or at least supported that compiler version.

Do we know what the motivation was for dropping VS2013 support in googletest? I'm wondering if we can make a case for reverting that decision. We may also want to consider switching to a different test harness if googletest doesn't plan to support older compilers.

As a last resort, we can always disable unit tests on VS2013. It's not ideal, but allowing the test harness to determine compiler requirements throughout the Vulkan tool chain seems backwards to me.

FWIW, the ecosystem group is looking into compiler requirements for the various projects --- there's an ongoing discussion on this topic in KhronosGroup/Vulkan-Ecosystem#8.

[johnkslang]

Conclusion of this is that we'll stay on 2013 for the time being (probably 2010 still for core parsing -> AST).