7652b659c4c33304ce628bbd0d929540aff1dfd0: Bug 1256502 - Disable C4319 to unblock compilation on VS2015; r?jmuizelaar draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:51:13 -0700 - rev 340096
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1256502 - Disable C4319 to unblock compilation on VS2015; r?jmuizelaar As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 4eBICvkzErY
9766fe8038f3866e9f568a13c216d602724435e8: enable PGO draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 14:48:22 -0800 - rev 340095
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
enable PGO MozReview-Commit-ID: EdiNUx21iPr
91ca3642778619c7dcee45aca6c22882c0acb153: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:25:59 -0700 - rev 340094
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
f6b58510b28dd887240aec80a3bd49da7b66c86f: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340093
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
9d620d612721b2a664c9006e534d93b5524b9b32: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340092
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
a3f5432f6c4190924d06ac398f38793005fd9315: Bug 1256501 - Disable C4312 to unblock compilation on VS2015; r?aklotz draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:38:54 -0700 - rev 340091
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1256501 - Disable C4312 to unblock compilation on VS2015; r?aklotz As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: FoYEsdZxi28
1b3834ab7c3b48c20bf341194ae55d8972ccd962: Bug 1256499 - Disable C4311 and C4312 to unblock compilation on VS2015; r?bobowen draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:35:38 -0700 - rev 340090
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1256499 - Disable C4311 and C4312 to unblock compilation on VS2015; r?bobowen As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. But the warning occurs in third party code, so my hands are tied. MozReview-Commit-ID: BCXQcEejre9
432d20f646ee606df1c04278191bcd84a0092d34: Bug 1256498 - Disable C4838 to unblock compilation on VS2015; r?jrmuizel draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:31:03 -0700 - rev 340089
Push 12909 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:51:28 +0000
Bug 1256498 - Disable C4838 to unblock compilation on VS2015; r?jrmuizel As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 6uMZ2d1ZBji
312ea8f99889e27c3b21eb0f7813ab53ed902978: Bug 1256501 - Disable C4312 to unblock compilation on VS2015; r?aklotz draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:38:54 -0700 - rev 340088
Push 12908 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:39:17 +0000
Bug 1256501 - Disable C4312 to unblock compilation on VS2015; r?aklotz As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: FoYEsdZxi28
597b4cbe606ba441a86155276033c45080babe04: Bug 1256499 - Disable C4311 and C4312 to unblock compilation on VS2015; r?bobowen draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:35:38 -0700 - rev 340087
Push 12907 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:35:58 +0000
Bug 1256499 - Disable C4311 and C4312 to unblock compilation on VS2015; r?bobowen As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. But the warning occurs in third party code, so my hands are tied. MozReview-Commit-ID: BCXQcEejre9
b7bee94570c375a201eb43e29fa255b69144cfde: Bug 1256498 - Disable C4838 to unblock compilation on VS2015; r?jrmuizel draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:31:03 -0700 - rev 340086
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1256498 - Disable C4838 to unblock compilation on VS2015; r?jrmuizel As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 6uMZ2d1ZBji
4351078c1300834bee15049c304b04bbe14aeda0: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:25:59 -0700 - rev 340085
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
8bb6edf736c6ac974153c8c63e0cf08e8ccce309: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340084
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
cf273f8d8d686c911720de3a2935daf28bce88af: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340083
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
1c3bb81b83315d78751de3ce521fc1d72d16de77: Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:14:57 -0700 - rev 340082
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 9Dc5eeXw52R
87fd56990419827490088507f5c0ca798cf84821: Bug 1256464 - Use LPSTR instead of LPVOID to avoid C4477 on VS2015; r?froydnj draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:18:42 -0700 - rev 340081
Push 12906 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:31:26 +0000
Bug 1256464 - Use LPSTR instead of LPVOID to avoid C4477 on VS2015; r?froydnj Without this change, Visual Studio 2015 complains: mozglue/misc/StackWalk.cpp(261): warning C4477: 'fprintf' : format string '%s' requires an argument of type 'char *', but variadic argument 2 has type 'LPVOID' MozReview-Commit-ID: HIAs5L57Nd1
17874e122b346a41f9473eda5dd17db350fae97a: Bug 1256464 - Use LPSTR instead of LPVOID to avoid C4477 on VS2015; r?froydnj draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 17:18:42 -0700 - rev 340080
Push 12905 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:19:28 +0000
Bug 1256464 - Use LPSTR instead of LPVOID to avoid C4477 on VS2015; r?froydnj Without this change, Visual Studio 2015 complains: mozglue/misc/StackWalk.cpp(261): warning C4477: 'fprintf' : format string '%s' requires an argument of type 'char *', but variadic argument 2 has type 'LPVOID' MozReview-Commit-ID: HIAs5L57Nd1
e2b9d258ea9ab7665b79e75ec3a3c51673aa1f49: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340079
Push 12905 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:19:28 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
393a0bf63aaef2a84bc166f035d7d3e97b88f8b8: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340078
Push 12905 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:19:28 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
eb6010f6d3ef8c4ad3ec150084e2dde9e159031a: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340077
Push 12905 by gszorc@mozilla.com at Tue, 15 Mar 2016 00:19:28 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip