Visual Studio 2015 Update 3 has been out for a few months. It appears
stable. So let's start using it.
As part of this, we also update the Windows SDK to the version
corresponding with the Windows 10 Anniversary Update (10.14393.0).
MozReview-Commit-ID: C36sRlKqa8t
--HG--
extra : rebase_source : 2fd46d6053d3eaf62dd8b2b291881c5172cc6056
autospider builds set VSPATH before sourcing
build/win*/mozconfig.vs-latest, so VSWINPATH was never set. Furthermore,
the way it sets variables for the build system relies on the variable
going through and export from mk_add_options, which
mk_export_correct_style conveniently does for us.
- Update the tooltool manifests to use the new package.
- Update mozconfig paths to reflect MSVC tooltool package changes.
--HG--
extra : rebase_source : 2f2da35ec1d1b3fb5ca9210951d9ac3a38a2bd75
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 94527a0be3f107991998185903f1c6cf6e190f9f
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders 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
--HG--
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
extra : intermediate-source : 559a80645f20706e1eaaeed863e90c2d35ff7644
Currently it will fail with errors such as:
Insufficient debug information (private symbols are needed) or code from
unknown language. The following modules didn't have full symbols:
nsBrowserApp.obj
AppData.obj (xpcomglue_staticruntime.lib)
FileUtils.obj (xpcomglue_staticruntime.lib)
nsCRTGlue.obj (xpcomglue_staticruntime.lib)
nsXPCOMGlue.obj (xpcomglue_staticruntime.lib)
We need to turn this back on when clang-cl grows more debug
info support.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
While bug 903369 added some kind of wrapping, msys mangling on Windows made
it hard to make the python wrapper invoke subconfigures itself. This change
overcomes this, allowing to run subconfigures entirely independently of
the main configure if necessary, or to do more fancy checks without having
to resort to m4 and shell.
Gregory Szorc
Mike Hommey
Carsten "Tomcat" Book
Tom Tromey
Wes Kocher
Chris Manchester
Jeff Gilbert
Mike Shal
George Wright
aleth
Ehsan Akhgari
Birunthan Mohanathas
Nathan Froyd
Gijs Kruitbosch
Kartikaya Gupta
Makoto Kato
Brian Smith
Masatoshi Kimura
David Major
Tim Abraldes
ABE Hiroki (hATrayflood)