Re: Dropping support for MSVC2012
Ted Mielczarek wrote: Especially with something like MSVC, where some contributors have actually paid for Pro versions of the suite and telling them to upgrade involves spending actual money that can be a huge deterrent. That's unfortunate since the professional VC2005, VC2008, VC2010 and now VC2013 compilers were always freely available, it was just the IDE that you had to pay for (or use the cut-down Express version which didn't include e.g. the just-in-time debugger or the SDK (which was freely available anyway)). -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On Fri, Jan 2, 2015, at 05:06 PM, Ehsan Akhgari wrote: FWIW to the best of my knowledge, we have kept the last two MSVC releases supported for quite a long time, but I don't know if there has ever been a good reason for that (besides people having them installed locally.) I would very much like us to change that tradition! I believe the only real historical justification for this has been try not to break people's dev environments because that's a PITA. Especially with something like MSVC, where some contributors have actually paid for Pro versions of the suite and telling them to upgrade involves spending actual money that can be a huge deterrent. In general when it's not a huge hassle for us supporting slightly out-of-date toolchains is better for our contribution story. However...given Microsoft's new stance on Visual C++, and the fact that you can get Visual Studio 2013 Community Edition[1] for free, which is exactly the Professional version licensed for use on open source and personal projects, I don't think unsupporting VC2012 would be particularly onerous. It would certainly inconvenience a few people that have already installed 2012 and now need to go install 2013 (which does take some time) but if we aren't consistently providing a build that works with 2012 then we're already inconveniencing those people, we're just not doing it in an upfront, straightforward manner. -Ted 1. http://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/1/2015 6:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. I'll give this thread another day for feedback for people who may have been away for the holidays, then I'll file the bug. Ideally we should get this done before next Monday's uplift so we don't jerk people around with dropping MSVC compiler support in two consecutive Gecko releases. Also, IIUC, this also means we can drop support for any Windows SDK 8.1. So that's nice too. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-04 11:53 PM, Dan Glastonbury wrote: On 3/01/2015 6:22 am, Ehsan Akhgari wrote: Yes, people should be discouraged from using MSVC2012 locally. Please note that: a) It is impractical for Mozilla to test every single toolchain that every single developer out there uses. If you want any kind of guarantee that your builds will keep working, you should use MSVC2013 on trunk and MSVC2010 on older versions than 37. b) MSVC2012 has *never* been a supported compiler in the second sense, and we have never used it on our infra (except for a short while for testing unofficial Win64 builds, and I believe that is no longer the case.) This is news to me. I've been using VS2012 since I started at Mozilla in Sept 2013, so I was a bit dismayed to have my build on windows break on returning from Xmas/NY break. Ehsan, do you have any guidance on the version of VS2013 we should be using locally? I have successful built trunk after installing VS2013 Community, for which its documentation states: An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: [...] contributing to open source projects. Any version would do, I think that the toolchain and the headers/libs shipped with all Visual Studio editions are the same. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-05 8:09 AM, Ryan VanderMeulen wrote: On 1/1/2015 6:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. I'll give this thread another day for feedback for people who may have been away for the holidays, then I'll file the bug. Ideally we should get this done before next Monday's uplift so we don't jerk people around with dropping MSVC compiler support in two consecutive Gecko releases. The bug with a patch is: bug 1117820. I'll land it tomorrow (or when it gets reviewed after that) if there is no other objections in the next day or so. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/5/15 12:58 PM, Philip Chee wrote: How close are we to being able to compile Firefox with clang on Windows? IIRC clang is free/libre - but not copy-left. Bug 752004 is the meta bug tracking work (mostly Ehsan's :) to build Firefox with clang-cl on Windows. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On Mon, Jan 05, 2015 at 01:13:28PM -0800, Kent James wrote: On 1/4/2015 3:43 PM, Mike Hommey wrote: I don't think anyone in their right mind would have installed 2012 after we dropped support for 2010, because the current version was 2013 at the time, and what's the point to upgrade if it's not for the current version? I am not objecting to dropping support for VS2012, but just to repeat what I previously said, this person in his right mind installed VS2012 recently to have a single version of a build environment that works from esr24 - trunk. That is a big advantage, but the prevailing opinion is that it is not enough of an advantage to maintain support. If I had my choice, VS2012 support would be logically dropped when gecko 31 support was dropped. But that would actually not solve my issues, since I will be compiling with gecko 31 long after official support is dropped, and it is clear that VS2012 will be gone long before then. So that is my opinion, but that is not the prevailing view, and I can accept that. We dropped support for 2010 during this cycle. Esr24 was not supported anymore already, why do you need to build it? Does esr31 actually fail to build with 2013? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/5/2015 3:12 PM, Mike Hommey wrote: On Mon, Jan 05, 2015 at 01:13:28PM -0800, Kent James wrote: We dropped support for 2010 during this cycle. Esr24 was not supported anymore already, why do you need to build it? Does esr31 actually fail to build with 2013? Mike I need to build esr24 because I am building a binary extension. Plenty of users are still on esr24 / Thunderbird 24. Actually we only fully unthrottled updates from TB 24 to TB 31 a few weeks ago, and there is still debate about whether that actually occurred or not. (Thunderbird volunteers, even though they are mostly responsible for the program now, have very little access to metrics that would actually tell us what version our users are running). (I may be the only person who builds, using the same C++ source files, esr24 - central. Makes for some creative moz.build files). Let me trying build esr31 from VS2013. I've been assuming it failed since there were patches that were required post-esr31 to make Thunderbird build with VS2013 IIRC. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/5/2015 3:30 PM, Kent James wrote: On 1/5/2015 3:12 PM, Mike Hommey wrote: On Mon, Jan 05, 2015 at 01:13:28PM -0800, Kent James wrote: ... Does esr31 actually fail to build with 2013? Mike Let me trying build esr31 from VS2013. I've been assuming it failed since there were patches that were required post-esr31 to make Thunderbird build with VS2013 IIRC. OK I tried it, and I was not correct. Thunderbird 31 does build with Visual Studio 2013. So I guess this is a non-issue. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-05 8:10 PM, Kent James wrote: On 1/5/2015 3:30 PM, Kent James wrote: On 1/5/2015 3:12 PM, Mike Hommey wrote: On Mon, Jan 05, 2015 at 01:13:28PM -0800, Kent James wrote: ... Does esr31 actually fail to build with 2013? Mike Let me trying build esr31 from VS2013. I've been assuming it failed since there were patches that were required post-esr31 to make Thunderbird build with VS2013 IIRC. OK I tried it, and I was not correct. Thunderbird 31 does build with Visual Studio 2013. So I guess this is a non-issue. That's great news, thanks for giving it a shot! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-05 3:58 PM, Philip Chee wrote: On 05/01/2015 07:43, Mike Hommey wrote: On Sun, Jan 04, 2015 at 02:28:30PM +0800, Philip Chee wrote: To me, the default answer to whether we should keep supporting MinGW is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) There is a big difference, though. There is a benefit from compiling with mingw, in that it's a free/libre toolchain, which MSVC isn't. People who do want to build Firefox or a Gecko-based product can do so without using a proprietary compiler. This has value to a lot of people. But once you have to choose between one version of a proprietary compiler and another, there is no such difference anymore. How close are we to being able to compile Firefox with clang on Windows? IIRC clang is free/libre - but not copy-left. We can build Firefox with clang-cl on Windows right now but that still depends on the rest of the Microsoft toolchain for now. Note that we regularly break mingw builds, probably much more often than we've broken MSVC 2012 builds, and we still accept fixes for those breakages. The situation is no different with MSVC 2012. Now, the question whether it's worth bothering with MSVC 2012 fixes is an interesting one, because of that lack of philosophical difference between 2012 and 2013. If you've come your way to install 2012, you can just as well upgrade to 2013. The benefit is better support for modern C++. And that, combined with the fact that 2012 has never been a toolchain we use on automation, make a case for dropping support for 2012. Looking at it another way, the only reason I can see that people are currently using 2012 is that they wanted something more modern than 2010 for some reason (I guess there are IDE changes that are worth?). They've had to endure build failures from time to time because 2012 was not what's used on automation. I don't think anyone in their right mind would have installed 2012 after we dropped support for 2010, because the current version was 2013 at the time, and what's the point to upgrade if it's not for the current version? So, keeping support for 2012 is essentially keeping support for people that decided to upgrade before everyone for some reason. They've had a long run, they can be forced to upgrade now. You are probably right but then it would have been better to have unsupported VS2012 at the same time as VS2010 instead of dropping VS2012 only a brief interval after VS2010. Yes, but we cannot change the past, and it's only been three weeks or so since we dropped VS2010. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 05/01/2015 07:43, Mike Hommey wrote: On Sun, Jan 04, 2015 at 02:28:30PM +0800, Philip Chee wrote: To me, the default answer to whether we should keep supporting MinGW is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) There is a big difference, though. There is a benefit from compiling with mingw, in that it's a free/libre toolchain, which MSVC isn't. People who do want to build Firefox or a Gecko-based product can do so without using a proprietary compiler. This has value to a lot of people. But once you have to choose between one version of a proprietary compiler and another, there is no such difference anymore. How close are we to being able to compile Firefox with clang on Windows? IIRC clang is free/libre - but not copy-left. Note that we regularly break mingw builds, probably much more often than we've broken MSVC 2012 builds, and we still accept fixes for those breakages. The situation is no different with MSVC 2012. Now, the question whether it's worth bothering with MSVC 2012 fixes is an interesting one, because of that lack of philosophical difference between 2012 and 2013. If you've come your way to install 2012, you can just as well upgrade to 2013. The benefit is better support for modern C++. And that, combined with the fact that 2012 has never been a toolchain we use on automation, make a case for dropping support for 2012. Looking at it another way, the only reason I can see that people are currently using 2012 is that they wanted something more modern than 2010 for some reason (I guess there are IDE changes that are worth?). They've had to endure build failures from time to time because 2012 was not what's used on automation. I don't think anyone in their right mind would have installed 2012 after we dropped support for 2010, because the current version was 2013 at the time, and what's the point to upgrade if it's not for the current version? So, keeping support for 2012 is essentially keeping support for people that decided to upgrade before everyone for some reason. They've had a long run, they can be forced to upgrade now. You are probably right but then it would have been better to have unsupported VS2012 at the same time as VS2010 instead of dropping VS2012 only a brief interval after VS2010. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/4/2015 3:43 PM, Mike Hommey wrote: I don't think anyone in their right mind would have installed 2012 after we dropped support for 2010, because the current version was 2013 at the time, and what's the point to upgrade if it's not for the current version? I am not objecting to dropping support for VS2012, but just to repeat what I previously said, this person in his right mind installed VS2012 recently to have a single version of a build environment that works from esr24 - trunk. That is a big advantage, but the prevailing opinion is that it is not enough of an advantage to maintain support. If I had my choice, VS2012 support would be logically dropped when gecko 31 support was dropped. But that would actually not solve my issues, since I will be compiling with gecko 31 long after official support is dropped, and it is clear that VS2012 will be gone long before then. So that is my opinion, but that is not the prevailing view, and I can accept that. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On Sun, Jan 04, 2015 at 02:28:30PM +0800, Philip Chee wrote: On 03/01/2015 04:22, Ehsan Akhgari wrote: To me, the default answer to whether we should keep supporting MSVC2012 is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) To me, the default answer to whether we should keep supporting MinGW is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) There is a big difference, though. There is a benefit from compiling with mingw, in that it's a free/libre toolchain, which MSVC isn't. People who do want to build Firefox or a Gecko-based product can do so without using a proprietary compiler. This has value to a lot of people. But once you have to choose between one version of a proprietary compiler and another, there is no such difference anymore. Note that we regularly break mingw builds, probably much more often than we've broken MSVC 2012 builds, and we still accept fixes for those breakages. The situation is no different with MSVC 2012. Now, the question whether it's worth bothering with MSVC 2012 fixes is an interesting one, because of that lack of philosophical difference between 2012 and 2013. If you've come your way to install 2012, you can just as well upgrade to 2013. The benefit is better support for modern C++. And that, combined with the fact that 2012 has never been a toolchain we use on automation, make a case for dropping support for 2012. Looking at it another way, the only reason I can see that people are currently using 2012 is that they wanted something more modern than 2010 for some reason (I guess there are IDE changes that are worth?). They've had to endure build failures from time to time because 2012 was not what's used on automation. I don't think anyone in their right mind would have installed 2012 after we dropped support for 2010, because the current version was 2013 at the time, and what's the point to upgrade if it's not for the current version? So, keeping support for 2012 is essentially keeping support for people that decided to upgrade before everyone for some reason. They've had a long run, they can be forced to upgrade now. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 3/01/2015 6:22 am, Ehsan Akhgari wrote: Yes, people should be discouraged from using MSVC2012 locally. Please note that: a) It is impractical for Mozilla to test every single toolchain that every single developer out there uses. If you want any kind of guarantee that your builds will keep working, you should use MSVC2013 on trunk and MSVC2010 on older versions than 37. b) MSVC2012 has *never* been a supported compiler in the second sense, and we have never used it on our infra (except for a short while for testing unofficial Win64 builds, and I believe that is no longer the case.) This is news to me. I've been using VS2012 since I started at Mozilla in Sept 2013, so I was a bit dismayed to have my build on windows break on returning from Xmas/NY break. Ehsan, do you have any guidance on the version of VS2013 we should be using locally? I have successful built trunk after installing VS2013 Community, for which its documentation states: An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: [...] contributing to open source projects. thanks - DanG ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 04/01/15 19:28, Philip Chee wrote: To me, the default answer to whether we should keep supporting MinGW is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) I believe the Tor project uses it for reproducible builds on Windows: https://air.mozilla.org/why-and-how-of-reproducible-builds-distrusting-our-own-infrastructure-for-safer-software-releases/ Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 4:36 AM, Kent James wrote: On 1/1/2015 3:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/1/2015 3:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 1:31 PM, Kent James wrote: On 1/2/2015 6:23 AM, Ehsan Akhgari wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. What has become clear is that MVCV 2012 is NOT actually supported in the second sense, but only in the first sense. That is, we do check in patches that break VS 2012, and those patches are not backed out when the breakage is discovered. Yes, exactly my point. The way to fix that is by adding automatic builders that test for VS 2012 breakage. If that is not done, then people should be strongly discouraged from using VS 2012 rather than saying it is supported. Yes, people should be discouraged from using MSVC2012 locally. Please note that: a) It is impractical for Mozilla to test every single toolchain that every single developer out there uses. If you want any kind of guarantee that your builds will keep working, you should use MSVC2013 on trunk and MSVC2010 on older versions than 37. b) MSVC2012 has *never* been a supported compiler in the second sense, and we have never used it on our infra (except for a short while for testing unofficial Win64 builds, and I believe that is no longer the case.) The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. I would hope that you would be considering the larger question of what is optimal for the developer community, and not simply what does not break mozilla-central. Yes I suppose that developers can figure out how to install multiple versions of VS on their computers, but that just adds one more obstacle to developing with Mozilla. Isn't making it easier to contribute supposed to be a goal? Developers should use MSVC2013 locally. And that is true no matter whether we decide to keep or drop support for MSVC2012. But actually what will probably happen is that people will just install VS 2013, and then when it comes to to check if their patch runs on esr31 they'll just not bother to recompile since it involves the onerous task of adding support to their system for an older compiler. That would have real quality ramifications. I know that what I'll do initially is just upgrade to VS 2013 on my development machine now and hope that I am sufficiently motivated to install VS2012 when it comes time to test something on esr31. Testing whether or not something works on esr31 is best done on the try server. Or, if that's something that you do very often, you need to install and use MSVC2010 for it. MSVC2012 is not the answer. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. If by adding official support you mean adding automatic tests, the benefit is to actually make VS 2012 viable, which it is increasingly becoming not viable. That is, you will actually do what you already claim that you do, namely we won't check in patches that require compiler features that 2012 does not support To be perfectly clear, I am very strongly opposed for us to spend any money or time to run and test MSVC2012 builds on our infra, even if we choose to keep support for it. We just cannot test every single build configuration out there, and yours is not the only one that differs from what we test on the infra. But I can see that the support for this is weak. I don't think that dropping VS 2012 support is correct obviously, but I am not going to continue arguing for it. I suppose I'll just have to deal with the additional complexity of supporting multiple VS versions. Add another few percentage points to the already-too-high fraction of my time spent just keeping things building instead of actually fixing bugs. To me, the default answer to whether we should keep supporting MSVC2012 is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/2/2015 6:23 AM, Ehsan Akhgari wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. What has become clear is that MVCV 2012 is NOT actually supported in the second sense, but only in the first sense. That is, we do check in patches that break VS 2012, and those patches are not backed out when the breakage is discovered. The way to fix that is by adding automatic builders that test for VS 2012 breakage. If that is not done, then people should be strongly discouraged from using VS 2012 rather than saying it is supported. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. I would hope that you would be considering the larger question of what is optimal for the developer community, and not simply what does not break mozilla-central. Yes I suppose that developers can figure out how to install multiple versions of VS on their computers, but that just adds one more obstacle to developing with Mozilla. Isn't making it easier to contribute supposed to be a goal? But actually what will probably happen is that people will just install VS 2013, and then when it comes to to check if their patch runs on esr31 they'll just not bother to recompile since it involves the onerous task of adding support to their system for an older compiler. That would have real quality ramifications. I know that what I'll do initially is just upgrade to VS 2013 on my development machine now and hope that I am sufficiently motivated to install VS2012 when it comes time to test something on esr31. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. If by adding official support you mean adding automatic tests, the benefit is to actually make VS 2012 viable, which it is increasingly becoming not viable. That is, you will actually do what you already claim that you do, namely we won't check in patches that require compiler features that 2012 does not support But I can see that the support for this is weak. I don't think that dropping VS 2012 support is correct obviously, but I am not going to continue arguing for it. I suppose I'll just have to deal with the additional complexity of supporting multiple VS versions. Add another few percentage points to the already-too-high fraction of my time spent just keeping things building instead of actually fixing bugs. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-01-02 2:03 PM, Brian Smith wrote: In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I realize that now. It is very unfortunate that the rules for using C++ in Mozilla code are not simply if it passes tryserver, it's OK. I hope that Mozilla accelerates its deprecation for old compilers (GCC less than 4.8, in particular, so that enum class can be used safely) and improves the automation. I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. First, I will back out the offending patch pending a resolution of this discussion, in the interests of being a good team player while this discussion unfolds. I've already asked a VS2012 user to review the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1117003#c3 However, I think my time is better spent arguing for dropping MSVC2012 support (and allowing = delete) than writing another = delete macro. So, let's try to resolve that it is OK to drop MSVC2012 support in Firefox 37 now. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. FWIW people fix compiler issues that cannot be tested on try server all the time. Because I develop on Windows and most others develop on Linux, I am disproportionately involved in these bugs, which usually affect differences in fail-on-warnings behavior between Windows and newer clang versions. That's why I'd like for us to resolve to move forward to increasing minimum compiler versions at a faster pace, because that seems like an effective and cheap way of reducing the occurrences of such issues. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 2:03 PM, Brian Smith wrote: Ehsan wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. FWIW people fix compiler issues that cannot be tested on try server all the time. It's OK if you don't want to do the work of fixing this yourself, but it seems like you are arguing against fixing the issue even if someone else provides a fix. Those are two separate matters. :-) The best solution is to just drop MSVC2012 support and officially allow features like = delete to be used from Gecko 37 onward. I am personally in favor of dropping support for MSVC2012, but before we do that, we should accept a fix for this particular issue. I would be interested to see if anyone else has a good reason for us to not drop support for MSVC2012. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Dropping support for MSVC2012
Ehsan wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. The best solution is to just drop MSVC2012 support and officially allow features like = delete to be used from Gecko 37 onward. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 3:32 PM, Brian Smith wrote: Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-01-02 2:03 PM, Brian Smith wrote: In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I realize that now. It is very unfortunate that the rules for using C++ in Mozilla code are not simply if it passes tryserver, it's OK. I hope that Mozilla accelerates its deprecation for old compilers (GCC less than 4.8, in particular, so that enum class can be used safely) and improves the automation. We are *very* interested in supporting fewer compiler versions as well. There are usually some factors that limit how aggressive we can be here (such as Linux distros using gcc versions older than what we'd like, and the b2g toolchain dependencies that we cannot necessarily control). Thanks for being patient while we get better at this. :-) FWIW to the best of my knowledge, we have kept the last two MSVC releases supported for quite a long time, but I don't know if there has ever been a good reason for that (besides people having them installed locally.) I would very much like us to change that tradition! I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. First, I will back out the offending patch pending a resolution of this discussion, in the interests of being a good team player while this discussion unfolds. I've already asked a VS2012 user to review the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1117003#c3 Thank you! However, I think my time is better spent arguing for dropping MSVC2012 support (and allowing = delete) than writing another = delete macro. So, let's try to resolve that it is OK to drop MSVC2012 support in Firefox 37 now. That's fair. :-) FWIW as I said elsewhere in the thread I think that the default answer at the lack of evidence to the contrary should be for us to drop MSVC2012, so perhaps you don't need to argue that strongly after all! Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 5:04 PM, RyanVM wrote: Are there any licensing/OS support/other issues that would encourage us to keep support for MSVC2012 hanging around? Both compilers support Windows 7 and above, and the express version of both compilers is freely (as in beer!) available (MSVC2012 cannot be downloaded from Microsoft any more, at least not in an obvious way.) So I think there is no difference that would encourage us to keep support for MSVC2012 around. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
Are there any licensing/OS support/other issues that would encourage us to keep support for MSVC2012 hanging around? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Dropping support for MSVC2012
Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
