Closed Bug 1259782 Opened 8 years ago Closed 8 years ago

Switch to Visual Studio 2015 Update 2

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox48 fixed)

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: gps, Assigned: gps)

References

Details

Attachments

(2 files)

Visual Studio 2015 Update 2 is in RC currently. As part of working on bug 1186060, I installed VS2015u2 and confirmed it builds mozilla-central (at least in basic local configurations - I never tried on Try).

Full list of changes in VS2015u2 is at https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx

https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/ also indicates there are several compiler bug fixes in it. So we should probably take the upgrade sooner than later.

Assuming it is released in the next month or so. we may also want to consider using VS2015u2 on all release channels so VS2015u1 isn't used for a single release. It feels sub-optimal to me to have to manage 3 Windows toolchains versions on shipping Firefox releases instead of 2. But maybe this isn't a huge deal in practice (it certainly isn't a big deal for the build config, as the toolchain is just an entry in the tooltool manifest). I'm thinking more for things like C++ compatibility.

The proposed C++ module owns the decision to switch to VS2015u2.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=df78bff64a89 shows VS2015u2 RC successfully building on Try. I had to disable warnings as errors because of at least one new warning (see https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b5a17f02f25). Other than that, it seems to have "just worked." (Ignore the gtest failure - that is due to gtest jobs not working on PGO builds.)
https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx

"Today, we are happy to announce the release of Visual Studio 2015 Update 2. This release focuses on stability and on responding to the feedback we’ve received on RTM and Update 1."
Depends on: 1261226
Depends on: 1261658
I have uploaded a copy of the Visual Studio 2015 Update 2 toolchain to tooltool:

{
"size": 332334599,
"visibility": "internal",
"digest": "a336cfc175f6b8451bf434bf61ac1f07f87ac024d02e65920a389743e52de7b8b975e05b23dda4c55333701fba6044a60a008b4ee789d2c20f72a9037e0a0ed2",
"algorithm": "sha512",
"filename": "vs2015u2.zip"
}
No longer depends on: 1261226
To support generating zip archives with more flexibility.

Review commit: https://reviewboard.mozilla.org/r/48509/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/48509/
Attachment #8744378 - Flags: review?(ted)
Attachment #8744379 - Flags: review?(ted)
I'm WFH today and have access to my Windows machine. So I might as well crank this one out since nobody else seems to be doing it.

Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=d7ff9ccce540
Assignee: nobody → gps
Status: NEW → ASSIGNED
Depends on: 1266615
Depends on: 1266614
Comment on attachment 8744378 [details]
MozReview Request: Bug 1259782 - Define zip archive path prefix argument; r?ted

https://reviewboard.mozilla.org/r/48509/#review45221

::: build/windows_toolchain.py:240
(Diff revision 1)
>          zip.add(sha256_path, sha256_manifest)
>  
>  
>  if __name__ == '__main__':
> -    if len(sys.argv) != 3:
> -        print('usage: %s create-zip <filename.zip>' % sys.argv[0])
> +    if len(sys.argv) != 4:
> +        print('usage: %s create-zip <prefix> <filename.zip>' % sys.argv[0])

I would probably just make this take a prefix and write $prefix.zip, but it doesn't really matter.
Attachment #8744378 - Flags: review?(ted) → review+
Comment on attachment 8744379 [details]
MozReview Request: Bug 1259782 - Build with Visual Studio 2015 Update 2; r?ted

https://reviewboard.mozilla.org/r/48511/#review45223
Attachment #8744379 - Flags: review?(ted) → review+
New Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=3133dbc8ed82 (adds 2 unlanded patches to fix warnings as errors). With these 2 patches, I can build in warnings as errors mode locally for both 32 and 64 bit builds. So I'm optimistic automation will be green.
Comment on attachment 8744378 [details]
MozReview Request: Bug 1259782 - Define zip archive path prefix argument; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48509/diff/1-2/
Comment on attachment 8744379 [details]
MozReview Request: Bug 1259782 - Build with Visual Studio 2015 Update 2; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48511/diff/1-2/
Depends on: 1266809
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c2efc37ad392 for the C4595 warning as error in the js shell. The rabbit holes keeps going deeper, heh.
Comment on attachment 8744378 [details]
MozReview Request: Bug 1259782 - Define zip archive path prefix argument; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48509/diff/2-3/
Comment on attachment 8744379 [details]
MozReview Request: Bug 1259782 - Build with Visual Studio 2015 Update 2; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48511/diff/2-3/
I decided to run the Visual Studio 2015 setup tool on my canonical toolchain building VM to see if there were any updates. There was an update to the "Tools 1.2 ... and Windows SDK" item. Basically, Tools 1.2.1 is now available. The same Windows SDK version was listed. So I clicked to update it.

I noticed the installer processed a reinstall of the Windows SDK. That felt a bit weird, but sure.

I produced a new zip archive of the toolchain. Being the paranoid person I am, I diffed the old vs2015u2 archive from the new one. Surprisingly, there were a number of changes:

* SDK/Include/shared/bugcodes.h
* SDK/Include/um/MDMRegistration.h
* SDK/Include/um/UIAutomationClient.h
* SDK/Include/um/UIAutomationClient.idl
* SDK/Include/um/UIAutomationCoreApi.h
* SDK/Include/um/WinUser.h
* SDK/Include/um/Winineti.h
* SDK/Include/um/commctrl.in1
* ...
* Nearly every .lib, .Lib, .dll, and .exe in the Windows SDK AFAICT
* Nearly every .dll in the UCRT redistributable AFAICT

The changes look benign. And a lot of the files have identical sizes. It looks like a version component was updated. e.g. the UCRT DLLs have their version bumped from e.g. 10.0.10586.15 to 10.0.10586.212. Also, the digital signature is from a later date.

This just appears to be a slightly newer build of the Windows SDK and UCRT. I can find references to 10.0.10586.212 on Microsoft's site as the current SDK version. So I'm going to upload a new archive and swap it in. I don't expect any major fallout.
Comment on attachment 8744379 [details]
MozReview Request: Bug 1259782 - Build with Visual Studio 2015 Update 2; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48511/diff/3-4/
Comment on attachment 8744379 [details]
MozReview Request: Bug 1259782 - Build with Visual Studio 2015 Update 2; r?ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48511/diff/4-5/
(In reply to Gregory Szorc [:gps] from comment #16)
> I decided to run the Visual Studio 2015 setup tool on my canonical toolchain
> building VM to see if there were any updates. There was an update to the
> "Tools 1.2 ... and Windows SDK" item. Basically, Tools 1.2.1 is now
> available. The same Windows SDK version was listed. So I clicked to update
> it.

Typo here - I clarified w/:gps that he meant 1.3/1.3.1 here, thus we have this change:

(In reply to Pulsebot from comment #20)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/e4926a91834c
https://hg.mozilla.org/mozilla-central/rev/67134dc3bf2b
https://hg.mozilla.org/mozilla-central/rev/d6ea7c8e2449
https://hg.mozilla.org/mozilla-central/rev/e4926a91834c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: