761321 - Switch experimental win8 builds on elm to use VS2012

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Armen [:armenzg]]

jimm says that we are deciding to switch to the VS2012 release candidate.
I will be installing later on the professional version.
http://www.microsoft.com/visualstudio/11/en-us/downloads#professional
I will install this on the five machines that should be taking metro builds.

We might also have to have to adjust the path for meta data (bug 755153).

Comment 1

[Armen [:armenzg]]

jimm, would switching to VS2012 make the XP work that Ehsan was/is working on more difficult?

Adding Ehsan just in case he needed to know as well what we are aiming to.

Comment 2

[(no longer active)]

I have not started investigating that yet!

Comment 3

[Jim Mathies [:jimm]]

I don't think they fixed that in this release. We've been in contact with them and thus far they seem to be saying it's not going to change.

Comment 4

[Armen [:armenzg]]

I am going to work on this as releases allow me this week.

Comment 5

[Armen [:armenzg]]

Attachment: mozconfig changes for vs2012 rc

Installing on the default path is so much easier as unattended installations are not collaborating.

I am also trying to address:
https://bugzilla.mozilla.org/show_bug.cgi?id=755153#c5

Comment 6

[Jim Mathies [:jimm]]

export INCLUDE=

/c/Program Files/Microsoft Visual Studio 11.0/vc/include:
/c/Program Files/Microsoft Visual Studio 11.0/vc/atlmfc/include:

On my local system, these two are in the X86 folder. Maybe this is different for our builders?

/c/Program\ Files\ \(x86\)/Windows\ Kits/8.0/include/shared:
/c/Program\ Files\ \(x86\)/Windows\ Kits/8.0/include/um:
/c/Program\ Files\ \(x86\)/Windows\ Kits/8.0/include/winrt:

These match my Kit folder.


export LIBPATH=

/c/Program Files/Microsoft Visual Studio 11.0/vc/lib:
/c/Program Files/Microsoft Visual Studio 11.0/vc/atlmfc/lib:
/c/Program Files/Microsoft Visual Studio 11.0/vc/vcpackages:

similar here, I have these but they are in the x86 folder.

/c/Program\ Files\ \(x86\)/Microsoft\ SDKs/Windows/v8.0/ExtensionSDKs/Microsoft.VCLibs/11.0/References/CommonConfiguration/neutral:
/c/Program\ Files\ \(x86\)/Windows\ Kits\ 8.0/References/CommonConfiguration/Neutral

These match mky kit folder.


export LIB=

/c/Program Files/Microsoft Visual Studio 11.0/vc/lib:
/c/Program Files/Microsoft Visual Studio 11.0/vc/atlmfc/lib:

same here.

/c/Program\ Files\ \(x86\)/Windows\ Kits/8.0/lib/win8/um/x86

This matches.

export PATH="
/c/Tools/msvs11/Common7/IDE:
/c/Tools/msvs11/VC/BIN:
/c/Tools/msvs11/Common7/Tools:
/c/Tools/msvs11/VC/vcpackages:
/c/Program Files (x86)/Windows Kits/8.0/bin/x86:
${PATH}"


export WIN32_REDIST_DIR=
'/c/Tools/msvs11/VC/redist/x86/Microsoft.VC110.CRT'

Don't we need to point these to the new install location?

Comment 7

[Armen [:armenzg]]

Attachment: add w64-ix-slave043 to the group and fix VS110COMNTOOLS

Comment 8

[Armen [:armenzg]]

Attachment: adjust group of slaves and fix VS110COMNTOOLS

Comment 9

[Rail Aliiev [:rail]]

In production 2012-06-22 09:30 PT

Comment 10

[Armen [:armenzg]]

Attachment: mozconfig changes for vs2012 rc

This got landed on elm already:
https://hg.mozilla.org/projects/elm/rev/0420f5e07dbd

Comment 11

[Armen [:armenzg]]

Attachment: jemalloc issue work around

We also landed this to work around some jemalloc issues (I think):
https://hg.mozilla.org/projects/elm/rev/ab47200a0c73

Comment 12

[Armen [:armenzg]]

This is fixed:
https://tbpl.mozilla.org/?tree=Elm&jobname=metro

The jobs are showing up orange but I will fix that next.

I will fix symbols and tests in bug 767477.

Comment 13

[Jim Mathies [:jimm]]

(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #11)
> Created attachment 635816 [details] [diff] [review]
> jemalloc issue work around
> 
> We also landed this to work around some jemalloc issues (I think):
> https://hg.mozilla.org/projects/elm/rev/ab47200a0c73

That doesn't appear to have helped, I was just testing the latest builds. I landed another patch that might address the problem. The issue is covered by bug 703135, which looks to be a compiler issue in the RC toolset.

Comment 14

[Armen [:armenzg]]

Are we now depending on bug 703135? Should I set the dependency accordingly?

Comment 15

[Jim Mathies [:jimm]]

(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #14)
> Are we now depending on bug 703135? Should I set the dependency accordingly?

Don't think we need to now. When we get into setting up test runs there are probably mochitests that tickle it but if I haven't found a fix I can disable theora to avoid it. As far as release/debug builds and the symbols work though, it shouldn't be an issue.

One thing I did do today was to disable the prerelease welcome page for elm builds. This had a webm video embedded in it that triggered that bug. So opening fresh builds should be fine. I tested this on my system today with the latest elm builds and they are loading fine.

I'll be looking more at it next week so hopefully I'll figure something out before it causes any problems.

Comment 16

[Jim Mathies [:jimm]]

Looks like all the vs11 builders we had have been upgraded.

Comment 17

[Yuhong Bao]

As another note, VC11 defaults to SSE2 codegen. This can be disabled by using /arch:IA32.