774910 - (enable-8.0sdk) Migrate mozilla build to the Windows 8.0 SDK

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Matthew Larrain[:MaRu]]

21:03 < MaRu> got another possible change I'd like your thoughts on, the Windows SDK that gets installed (currently version 7) also installs .net framework 3.5 but it doesn't allow for a silent or quiet install. Would we be safe to install version 7.1 that installs .net framwork 4.0 instead?
21:12 < armenzg> MaRu: /me thinks
21:20 < armenzg> MaRu: I will ask in #developers
21:23 < armenzg> MaRu: I asked and they say it should not be a problem but bsmedberg says "I wouldn't immediately ship a release without testing, of course ;-)"
21:24 < armenzg> MaRu: in other words, we could have problem without wanting it
21:24 < armenzg> MaRu: the only way out would be do a staging release with modified win64 machines and ask QA to qualify the builds
21:25 < armenzg> in other words, it is expensive (people-resources), it requires extra coordination and need to be done early on a release schedule and hope that there is no chemspill
21:26 < armenzg> I don't want to be a party pooper but wanted to give you all the info that needs to be taken into consideration
21:27 < arr> (we should record this info in a bug)

It's going to be tough to install version 7 as there is no quiet install method. I can for the time being try and build an MSI for it and hopefully that will work for us. We should however look at moving to the newer 7.1 build out for this.

Comment 1

[Armen [:armenzg]]

Adding jimm and bsmedberg in case they want to add anything else.

Comment 2

[Matthew Larrain[:MaRu]]

jimm and bsmedberg do you have any insight on this? Just trying to stay on point with using updated tools if possible as using the same toolset is easier to troubleshoot/manage.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Matthew Larrain[:MaRu] from comment #2)
> jimm and bsmedberg do you have any insight on this? Just trying to stay on
> point with using updated tools if possible as using the same toolset is
> easier to troubleshoot/manage.

The difference between 7.0 and 7.1 is the .net version - 

http://en.wikipedia.org/wiki/Microsoft_Windows_SDK

Since vc10 came with the 7.1 sdk I seriously doubt we would run into any problems by switching.

Comment 4

[Matthew Larrain[:MaRu]]

I agree with Jim as we have to install net framework 4.0 for VS2012 anyways.

Comment 5

[Amy Rich [:arr] [:arich]]

So who needs to sign off on this decision, hwine?  Can we switch to SDK version 7.1 for the new imaging process?

Comment 6

[Hal Wine [:hwine] use NI!]

I'll get a decision - ftr, this is for windows builders.

Comment 7

[Jim Mathies [:jimm]]

(In reply to Hal Wine [:hwine] from comment #6)
> I'll get a decision - ftr, this is for windows builders.

Have we considered maybe skipping 7.1 and jumping to 8.0? I know the gfx folks would appreciate this quite a bit.

Comment 8

[Armen [:armenzg]]

I don't think we can do this without testing and without landing a patch in a bunch of branches:
http://mxr.mozilla.org/mozilla-central/source/build/win32/mozconfig.vs2010-win64
http://mxr.mozilla.org/mozilla-central/source/build/win64/mozconfig.vs2010

Can we get a slave re-imaged with *just* 7.1 SDK and run it through staging and see what we hit?

Comment 9

[Hal Wine [:hwine] use NI!]

(In reply to Amy Rich [:arich] [:arr] from comment #5)
> So who needs to sign off on this decision, hwine?  Can we switch to SDK
> version 7.1 for the new imaging process?

Short answer: we can't switch SDK without a bunch of preliminary work.

We have to ensure that there continues to be a way to build all supported releases, including ESR. At the moment, we still believe these new builders-for-win-8 will also support all other windows platforms.

The next step in a 7.1 sdk qualification would be what is in comment #8

The first step to qualify an 8.x (comment #7) would be for dev to show 8.x still generates a usable binary for the currently supported OS: XP, win7(32&64)

Comment 10

[Jim Mathies [:jimm]]

(In reply to Hal Wine [:hwine] from comment #9)
> (In reply to Amy Rich [:arich] [:arr] from comment #5)
> > So who needs to sign off on this decision, hwine?  Can we switch to SDK
> > version 7.1 for the new imaging process?
> 
> Short answer: we can't switch SDK without a bunch of preliminary work.
> 
> We have to ensure that there continues to be a way to build all supported
> releases, including ESR. At the moment, we still believe these new
> builders-for-win-8 will also support all other windows platforms.
> 
> The next step in a 7.1 sdk qualification would be what is in comment #8
> 
> The first step to qualify an 8.x (comment #7) would be for dev to show 8.x
> still generates a usable binary for the currently supported OS: XP,
> win7(32&64)

We're going to take the 8.0 sdk for a spin with vc2010 in the next few weeks, will report back on the results.

Comment 11

[Jim Mathies [:jimm]]

I've just finished up doing basic testing with the win8 sdk in bug 799188. Everything look ok. I've posted basic sdk setup there as well.

Next steps:

1) Work out how to install and configure the sdk on a 2008 builder.
2) get a builder set up doing 32-bit builds that QA can smoke test.
2) point those builds at test slaves and work up a full suite of test runs.

Comment 12

[Matthew Larrain[:MaRu]]

Awesome news Jim thanks for keeping me up to speed on this. Once I get around to working on the 08 builders again I can try automating the SDK install.

Comment 13

[Jim Mathies [:jimm]]

(In reply to Matthew Larrain[:MaRu] from comment #12)
> Awesome news Jim thanks for keeping me up to speed on this. Once I get
> around to working on the 08 builders again I can try automating the SDK
> install.

A couple notes -

1) we'll need the 8.0 sdk to build the metro browser frontend on mc. We're currently working on back porting the metro widget bits to vs 2010, but we'll still need the sdk for api definitions. Which means all builders will have to migrate to 8.0. The back porting work should be complete in a week or so.

[Once we've confirmed this works this bug will gain the attention of people driving the metro release.]

2) we may need to make a minor change to an 8.0 sdk header. It's a simple string replace. I'm hoping this is something we can automate as a post the install step?

Comment 14

[Matthew Larrain[:MaRu]]

Currently our builders are running in a workgroup so there is no quick or centrally manged way to push this to all the builders. I will look at the 8.0 SDK and see how easily I can get the SDK to install via automation.

Comment 15

[Matthew Larrain[:MaRu]]

Good news the 8.0 SDK has command line flags for quiet install as well as where to install it to. I very much like this new SDK for those reason. we can automate the install fairly easily with this info. sdksetup.exe /quiet /installpath [path] /norestart

Comment 16

[Armen [:armenzg]]

If you get me a w64 slave with the newer SDK on it I can spin it on staging.

Let me know if you would like me to set a machine for you to test on.

Comment 17

[Matthew Larrain[:MaRu]]

I'd love it if you could get me a w64 box to test this on. I can work on it today as well.

Comment 18

[Armen [:armenzg]]

MaRu, w64-ix-slave79 has been set aside for you.

Comment 19

[Matthew Larrain[:MaRu]]

I have gotten SDK 8.0 to deploy with an automated task sequence in MDT.
The SDK has been installed on w64-ix-slave79 in C:\Program Files(x86)\Windows Kits\8.0

Comment 20

[Armen [:armenzg]]

I will run the slave through staging in bug 805553.

Comment 21

[Jim Mathies [:jimm]]

(In reply to Matthew Larrain[:MaRu] from comment #19)
> I have gotten SDK 8.0 to deploy with an automated task sequence in MDT.
> The SDK has been installed on w64-ix-slave79 in C:\Program
> Files(x86)\Windows Kits\8.0

Will we also be able to automate a change to a header? Specifically:

C:\Program Files (x86)\Windows Kits\8.0\Include\winrt\asyncinfo.h

line 67:

enum class AsyncStatus {

to

enum /*class*/ AsyncStatus {

Comment 22

[Matthew Larrain[:MaRu]]

yeah i can replace asyncinfo.h with a modified version of it.

Comment 23

[Matthew Larrain[:MaRu]]

Armen can we get confirmation of if we need to remove the old SDK before installing the new one or are we good to use both on there?

Comment 24

[Armen [:armenzg]]

We don't need to remove the previous SDK and in fact we should not since that is being used by older branches like the ESR.

I have put w64-ix-slave79 on the production pool but will need one more day of data to determine if the SDK deployment causes any regressions.

So far on staging it did not cause any problems.

Comment 25

[Matthew Larrain[:MaRu]]

Thanks for the update. Def. what I wanted to hear :)

Comment 26

[Jim Mathies [:jimm]]

One new twist with the 8.0 sdk - it does not include a redist folder. So we'll need to distribute the redist folder that comes with vs11 (assuming we aren't planning on installing it with this upgrade) to the builders so they have the crt we run with.

Comment 27

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #26)
> One new twist with the 8.0 sdk - it does not include a redist folder. So
> we'll need to distribute the redist folder that comes with vs11 (assuming we
> aren't planning on installing it with this upgrade) to the builders so they
> have the crt we run with.

Update to this, this turns out to be incorrect. We'll be distributing the vs10 runtime as usual.

Comment 28

[Jim Mathies [:jimm]]

Ok, Elm is now producing testable builds using the new 8.0 SDK and Visual Studio 2010.

Comment 29

[Jim Mathies [:jimm]]

(In reply to Alex Keybl [:akeybl] from comment #56)
> (In reply to Armen Zambrano G. [:armenzg] from comment #55)
> > Hi akeybl, lsblakk,
> > What is the process to request switching from current Windows 7.0 SDK to
> > Windows 8.0 SDK?
> > Do you know?
> 
> I think the right path forward would be an email to dev-platform that
> includes the proposal, reasoning for making the change, any known issues,
> and a request for any reasons to *not* move forward with the proposal.

Comment 30

[Dustin J. Mitchell [:dustin] (he/him)]

Armen, it looks like this is on you and jimm for the moment.  When we get prepared to install this on the builders, well, we'll figure that part out.

Comment 31

[Armen [:armenzg]]

We have figured out how to deploy it and we're going to do so today.
Let's keep this bug open to add this script to the task sequence when re-imaging win64 machines.
https://github.com/armenzg/bearded-ironman/blob/master/win2008_64bit/install_windows_standalone_sdk_8.0.bat

Feel free to move the files download to another location.

Let me know if you have any questions.

Comment 32

[Jim Mathies [:jimm]]

I've pushed a couple builds to try using the new sdk, so far everything looks good. I plan to push a few more to tweak path info until I get a minimalist set of lib, libpath, and include settings.

For the final landing of build config changes on mc we probably want to wait until the next merge, which will be the week of 2013-01-06.  I'll post final win64 builder config patches here once I'm done testing.

Comment 33

[Jim Mathies [:jimm]]

This brings up a question - are we using 32-bit builders currently for any release/mc/try builds? I haven't updated those configs since we didn't push the sdk out to 32-bit builders (bug 810141).

Comment 34

[Armen [:armenzg]]

We *only* use win32 builders for mozilla-esr10/comm-esr10 which will be done in February.
We don't need to deploy the newer SDK to them.

Comment 35

[Jim Mathies [:jimm]]

Path changes:

https://hg.mozilla.org/try/rev/efab8c7ddcd9

Comment 36

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #35)
> Path changes:
> 
> https://hg.mozilla.org/try/rev/efab8c7ddcd9

These are for 32-bit app build. Should I also update the 64-bit app build config and test? I'm guessing yes, even though we'll be dropping support, we probably want the config scripts to be up to date.

Comment 37

[Armen [:armenzg]]

(In reply to Jim Mathies [:jimm] from comment #36)
> (In reply to Jim Mathies [:jimm] from comment #35)
> > Path changes:
> > 
> > https://hg.mozilla.org/try/rev/efab8c7ddcd9
> 
> These are for 32-bit app build. Should I also update the 64-bit app build
> config and test? I'm guessing yes, even though we'll be dropping support, we
> probably want the config scripts to be up to date.

It will probably reduce the work to bring it up to date the day that we want to get it back going.

Thanks jimm.

Comment 38

[Armen [:armenzg]]

Hi jimm,
I'm trying to figure out what is the work left on this bug.
AFAIU we are done from the releng side.

The only thing I can think of is to take the Elm sub-pool and ask IT to re-image and make sure that the Windows 8 SDK gets installed properly.

Are you using this bug as a tracking bug? It sounds it should be a Build Config bug tracking on when you do the switch to the Windows 8 SDK on mozilla-central (rather than a Server Ops bug).

I would like to clarify this to make it clear what is left for Relops and Releng.

Thanks.

Comment 39

[Jim Mathies [:jimm]]

Attachment: build config patch v.1

Comment 40

[Jim Mathies [:jimm]]

(In reply to Armen Zambrano G. [:armenzg] from comment #38)
> Hi jimm,
> I'm trying to figure out what is the work left on this bug.
> AFAIU we are done from the releng side.

Looks that way.

> The only thing I can think of is to take the Elm sub-pool and ask IT to
> re-image and make sure that the Windows 8 SDK gets installed properly.

Yep, although there's no rush on that... we like having the dedicated pool. :) We should do this anyway so we are testing out the builder pool on elm from now until we land this for mc. Can you file a follow up?

> Are you using this bug as a tracking bug? It sounds it should be a Build
> Config bug tracking on when you do the switch to the Windows 8 SDK on
> mozilla-central (rather than a Server Ops bug).

Yes this bug can track other bugs if need be.

Comment 41

[Dustin J. Mitchell [:dustin] (he/him)]

From a talk with Armen and another talk with MaRu:

* we're going to try to avoid wholesale reimaging, preferring to install the SDK via SSH on existing hosts.  It's known how to do that -- I just need to know what /installpath to use, and when to do it

* the MDT process to build new machines with the SDK installed is basically in place - it just doesn't specify an /installpath yet, and probably should be tested once or twice more

Comment 42

[Armen [:armenzg]]

(In reply to Dustin J. Mitchell [:dustin] from comment #41)
> From a talk with Armen and another talk with MaRu:
> 
> * we're going to try to avoid wholesale reimaging, preferring to install the
> SDK via SSH on existing hosts.  It's known how to do that -- I just need to
> know what /installpath to use, and when to do it
> 
> * the MDT process to build new machines with the SDK installed is basically
> in place - it just doesn't specify an /installpath yet, and probably should
> be tested once or twice more

We took the default value. This means it is most likely not needed to be specified.

Nevertheless, here's the value:
"C:\Program Files (x86)\Windows Kits\8.0"

We can test re-imaging one or two machines.

Comment 43

[Dustin J. Mitchell [:dustin] (he/him)]

Oh, great, that makes things pretty easy.  I'll find you in irc today to borrow a machine to test on (I need to make sure the process works anyway, before MaRu goes)

Comment 44

[Amy Rich [:arr] [:arich]]

I've done a test deployment on w64-ix-slave20 (set aside by armen).  Please check that out and let us know if it works.

Comment 45

[Armen [:armenzg]]

(In reply to Amy Rich [:arich] [:arr] from comment #44)
> I've done a test deployment on w64-ix-slave20 (set aside by armen).  Please
> check that out and let us know if it works.

Hi arr,
We need to deploy this file as well:
https://bug810141.bugzilla.mozilla.org/attachment.cgi?id=681123
The difference is in line 66:
num class AsyncStatus {
vs
num *class* AsyncStatus {

This can be seen in:
https://github.com/armenzg/bearded-ironman/blob/master/win2008_64bit/install_windows_standalone_sdk_8.0.bat

FTR a new sdksetup.exe was issued in Nov. 15th which is different to what is on the IT servers (I'm pretty sure).

jimm, do you think the different SDKs should cause trouble?

arr, you can also take the install_windows_standalone_sdk_8.0.bat as is an use it if you want. The file would have to live somewhere different than dev-stage01 though.

Comment 46

[Armen [:armenzg]]

Feel free to re-image w64-ix-slave20 anytime.

FTR the modified file is not something that MaRu and us knew at the time.

Comment 47

[Dustin J. Mitchell [:dustin] (he/him)]

OK, so our test was a little premature..  any other details you want to share before we try again? :)

Comment 48

[Armen [:armenzg]]

(In reply to Dustin J. Mitchell [:dustin] from comment #47)
> OK, so our test was a little premature..  any other details you want to
> share before we try again? :)

All details are there! I should have been explicit in my last comment (that's what I attempted to do).

I wasn't sure what info or script was on your side.

Comment 49

[Jim Mathies [:jimm]]

(In reply to Armen Zambrano G. [:armenzg] from comment #45)
> FTR a new sdksetup.exe was issued in Nov. 15th which is different to what is
> on the IT servers (I'm pretty sure).
> 
> jimm, do you think the different SDKs should cause trouble?

I'm currently running this with no problems. Whatever they changed they didn't feel it had to be documented.

I'm confused though, they pulled that link down and then put it back up after the 15th, so I'm assuming the distribution to the win64 builders was with the new sdk? The comments in bug 810141 seem to indicate so.

Comment 50

[Armen [:armenzg]]

(In reply to Jim Mathies [:jimm] from comment #49)
> (In reply to Armen Zambrano G. [:armenzg] from comment #45)
> > FTR a new sdksetup.exe was issued in Nov. 15th which is different to what is
> > on the IT servers (I'm pretty sure).
> > 
> > jimm, do you think the different SDKs should cause trouble?
> 
> I'm currently running this with no problems. Whatever they changed they
> didn't feel it had to be documented.
> 
> I'm confused though, they pulled that link down and then put it back up
> after the 15th, so I'm assuming the distribution to the win64 builders was
> with the new sdk? The comments in bug 810141 seem to indicate so.

Correct. We ended up using the sdksetup.exe from the 15th. What I did notice between the two different SDKs is that the first one does not work anymore and the second one downloads several hundreds of MBs and that is why I had one more reason to do a StandaloneSDK
http://dev-stage01.build.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/sdks/sdksetup.nov13th.exe
* This is the old one which I renamed it to indicate the last day I used it
http://dev-stage01.build.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/sdks/sdksetup.exe
* This is the new one which downloads hundreds of MBs.
http://dev-stage01.build.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/sdks/sdksetup.zip
* This is the StandaloneSDK version of the new one

I hope this helps!

Comment 51

[Jim Mathies [:jimm]]

Comment on attachment 685665 [details] [diff] [review]
build config patch v.1

I need to update to these, I clipped out the msvc 10 atl headers, but we still rely on those in some places.

Comment 52

[Armen [:armenzg]]

Removing bug 815680 from blocking list as it is more accurate.

Comment 53

[Dustin J. Mitchell [:dustin] (he/him)]

I grabbed sdksetup.exe and stashed it in \\releng\data\apps\misc\bug774910 for safe-keeping.

Comment 54

[Jim Mathies [:jimm]]

Attachment: 64bit builder mozconfigs

Comment 55

[Jim Mathies [:jimm]]

Attachment: 64bit builder mozconfigs

- cleaned up comment headers

Comment 56

[Jim Mathies [:jimm]]

Pushed to try w/the patch in bug 827643 to get good win64 builds - 

https://tbpl.mozilla.org/?noignore=1&tree=Try&rev=bb40e60527b4

Comment 57

[Jim Mathies [:jimm]]

Attachment: 64bit builder mozconfigs

- removed a couple double colons in INCLUDES

Comment 58

[Jim Mathies [:jimm]]

full try run including talos:

https://tbpl.mozilla.org/?noignore=1&tree=Try&rev=72a4c5fcf318

Comment 59

[Jim Mathies [:jimm]]

Comment on attachment 699753 [details] [diff] [review]
64bit builder mozconfigs

This is shaping up nicely on try. Need a final r+ to land on m-c.

Comment 60

[Armen [:armenzg]]

Comment on attachment 699753 [details] [diff] [review]
64bit builder mozconfigs

LGTM.

Comment 61

[Jim Mathies [:jimm]]

https://hg.mozilla.org/mozilla-central/rev/0faa1d47ea80

Comment 62

[NVD]

http://blogs.msdn.com/b/vcblog/archive/2012/10/08/windows-xp-targeting-with-c-in-visual-studio-2012.aspx

See comment by Ibrahim Damlaj.

"The reason we have reintroduced the Windows 7 SDK is that the Windows 8 SDK has officially dropped support for Windows XP and Windows Server 2003. What this means is that the binaries under the “Windows Kits/8.0/bin” directory are no longer guaranteed to generate code that runs on Windows XP/2003. Additionally, the Windows 8 SDK headers and libs may have removed deprecated Windows XP APIs with no mitigation. As @Mike described above, you may choose to target the standard SDK by not switching  to v110_xp. However, if your application compiles and runs we cannot guarantee it will continue to do so in future releases and updates of Visual Studio."

Changing to Windows 8.0 SDK might or might not make Firefox incompatible with XP SP3. Just a heads up.

Comment 63

[Jim Mathies [:jimm]]

We are still using the msvc 10 tool chain so we don't have to worry about binary compat with xp. As far as the headers go we've seen no issues thus far. Mozilla's build targets a lower api set so I doubt the sdk itself can cause us any harm.