Repository navigation
build: drop support for VS 2013 in v7 #7484
Description
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.
Activity
joshgav commentedon Jun 29, 2016
Thoughts @AndrewPardoe @orangemocha @nodejs/platform-windows @mousetraps
AndrewPardoe commentedon Jun 30, 2016
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.
joaocgreis commentedon Jun 30, 2016
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
jasnell commentedon Jun 30, 2016
Given 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.
eljefedelrodeodeljefe commentedon Jul 1, 2016
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.
jwulf commentedon Jul 1, 2016
Do people still use Windows?
bnoordhuis commentedon Jul 1, 2016
Save snark for Twitter, please.
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.)
jasnell commentedon Jul 1, 2016
@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.
jasnell commentedon Jul 1, 2016
@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?
ChALkeR commentedon Jul 1, 2016
+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.
rvagg commentedon Jul 5, 2016
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?orangemocha commentedon Jul 5, 2016
+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
joaocgreis commentedon Sep 14, 2016
@jasnell Please use the new job
reis-iojs+releasefor the beta builds of v7 announced in #8503 . That job uses VS2015 automatically for v6 and above.The plan is to merge it with
iojs+releasewhen we start releasing v6 with VS2015. When that happens, onlyiojs+releasewill be used for everything.src: remove VS 2013 compatibility hacks
build: remove VS 2013 switch from vcbuild.bat
saper commentedon Sep 23, 2016
I have posted some proposed way of doing this in the sister bug (#7989 (comment))
saper commentedon Sep 23, 2016
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.joaocgreis commentedon Oct 11, 2016
Release Jenkins and test CI changed to build v7 with VS2015.
src: remove VS 2013 compatibility hacks
build: remove VS 2013 switch from vcbuild.bat