Repository navigation
build: drop support for VS 2013 in v7 #7484
Description
Activity
Thoughts @AndrewPardoe @orangemocha @nodejs/platform-windows @mousetraps
My opinion: move the compiler forward unless you know of specific reasons not to. VS offers multiple solutions for those who believe they can't move to the latest. For example, you can continue to compile solutions in VS 2015 using the VS 2013 project & build system.
We've been advising to use VS2015 to compile modules for some time, so I don't think this is going to be a big issue for most users. It's good to keep moving forward, and after the issues mentioned above, I think we should do this.
One thing to consider is our release infrastructure, we'll need different machines for VS2013 and VS2015. Could we move v6 to VS2015 before it turns LTS?
cc @nodejs/build
Reacted by Robert Jefe Lindstädt, Tierney Cyren and LinzGiven the number of small inconsistencies I've been hitting with vs2013 on things like the url parsing and http2 implementation, I'd definitely be +1 on dropping vs2013 in v7 and forward.
I'm not sure if we could get away with moving v6 to vs2015 exclusively at this point. That would be a discussion for the @nodejs/ctc tho. I certainly wouldn't mind.
As stated already, definitely in favour. Especially now that build tools are installable through a separate exe headlessly.
Since it's compatible down to XP we could actually set it lower, theoretically.
Do people still use Windows?
Reacted by Florian-R, Ingvar Stepanyan, Jeremiah Senkpiel, Michaël Zasso, Tierney Cyren, Jacob Francis Powers, Louis DeScioli, Uzo Olisemeka, W.T. Chang, Bert Belder and 2 moreReacted by Jacob Francis Powers, Sathish and Dominic GannawaySave snark for Twitter, please.
I'm not sure if we could get away with moving v6 to vs2015 exclusively at this point.
I personally don't see a problem with that when we're talking about building node from source.
As to add-ons, do we want to commit to supporting a compiler that is five or six years old by the time the v6 LTS branch gets EOL'd? Now that Visual C++ Build Tools exists, taking out a lot of the pain of building add-ons on Windows, I'm inclined to say 'no'.
(The question of support is applicable to older versions of gcc and clang too, of course.)
Reacted by Tierney Cyren, Yury and Saúl Ibarra Corretgé@bnordhuis ... good point. Definitely does not seem tenable. Thinking about it further, I think I'd be +1 on transitioning away from vs2013 in v6.
@nodejs/ctc ... does anyone have any strong feelings about maintaining vs2013 support in v6 and forward? If we do drop it, how do we want to go about messaging it?
+1 to dropping support for any old compiler in the next semver-major (i.e. v7), if that would reduce the number of hacks and/or maintenance costs, as long as that doesn't break any supported platform, or if that is forced on us by upstream (i.e. v8) or if we expect that it would be forced on us in near future.
Note: also +1 as treating any platform that isn't supported by the corresponding upstream as unsupported (e.g. Windows XP, Debian 6, OS X 10.8, CentOS 4, etc.), if we don't already.
No opinion on v6, but I would prefer if the final course of action on that would be decided before v6 goes into LTS mode.
I'm happy to defer to our Windows folks here, I know that things move a bit differently there than on Linux so perhaps this is perfectly reasonable.
I'm interested in the suggestion that we maintain 2013 support for addons. This seems like a worthy thing to do because putting demands on users to make sure they have 2015 is very different to demanding that of people building from source. However, I'm not sure I see a clear path to actually testing this that doesn't involve some pretty crazy Jenkins gymnastics. @joaocgreis can you think of a straightforward way to build with 2015 but
test-addonswith 2013?+1 on dropping support it makes the life of core developers easier. It would make sense to do this before v6 hits LTS.
We definitely need to keep supporting building native modules with VS 2013.
46 remaining items
- added 2 commits that reference this issue
on Sep 23, 2016 I have posted some proposed way of doing this in the sister bug (#7989 (comment))
Some info why we should be doing this carefully: the problem is that the code integrated with node via extensions (various third party libraries like libgit2 etc.) is usually not directly under extension authors control.
It takes some experience to find out some subtle issues thread local storage initialization etc. and this is hard to do in the foreign code.
Most currently written node modules use relatively simple C++ code (especially those written specifically for node). As more third-party libraries will be integrated some of them will used advanced C++ and C++11 features which will lead to some very hard to debug bugs, often appearing on some platform but not on another.
Fortunately node-sass and libsass (the C++ part) are maintained by the same group, so there is possibility to take some ABI compatibility considerations into account, but this is always a very difficult decision ("why can't I use C++ feature XX - because of node linking problems").
I think it pays to have a long-term ABI stability strategy (based on
PlatformToolsetversioning) and do not let people mix C++ ABI by accident.Reacted by Gibson FahnestockRelease Jenkins and test CI changed to build v7 with VS2015.
- added 2 commits that reference this issue
on Oct 11, 2016
Proposal: drop support for building node.js with VS 2013.
Motivation: VS 2013 has numerous bugs in its C++11 support and in general. The source tree is full of hacks that work around this broken compiler and pull requests sometimes strand on it (e.g. #5458.)
As to add-ons, we could extend VS 2013 support for our public headers for a while (and test that through test/addons) but V8 will probably force us to update the baseline there too. Chromium currently requires Visual Studio 2015 Update 2 so I expect V8 will follow suit sooner rather than later.