Closed
Bug 774910
(enable-8.0sdk)
Opened 12 years ago
Closed 11 years ago
Migrate mozilla build to the Windows 8.0 SDK
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mlarrain, Assigned: jimm)
References
(Depends on 1 open bug)
Details
(Whiteboard: [metro-mvp][LOE:-][metro-it2])
Attachments
(1 file, 3 obsolete files)
4.48 KB,
patch
|
armenzg
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
Adding jimm and bsmedberg in case they want to add anything else.
Updated•12 years ago
|
Assignee: server-ops-releng → mlarrain
Reporter | ||
Comment 2•12 years ago
|
||
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.
![]() |
Assignee | |
Comment 3•12 years ago
|
||
(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.
Updated•12 years ago
|
Summary: Issues using Windows SDK version 7 vs Windows SDK version 7.1 → Choose/test Windows SDK version 7.1 vs Windows SDK version 7
Reporter | ||
Comment 4•11 years ago
|
||
I agree with Jim as we have to install net framework 4.0 for VS2012 anyways.
Comment 5•11 years ago
|
||
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•11 years ago
|
||
I'll get a decision - ftr, this is for windows builders.
![]() |
Assignee | |
Comment 7•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
(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)
![]() |
Assignee | |
Comment 10•11 years ago
|
||
(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.
Updated•11 years ago
|
Summary: Choose/test Windows SDK version 7.1 vs Windows SDK version 7 → Choose/test Windows SDK version
![]() |
Assignee | |
Comment 11•11 years ago
|
||
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.
Reporter | ||
Comment 12•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 13•11 years ago
|
||
(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?
Reporter | ||
Comment 14•11 years ago
|
||
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.
Reporter | ||
Comment 15•11 years ago
|
||
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•11 years ago
|
||
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.
Reporter | ||
Comment 17•11 years ago
|
||
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•11 years ago
|
||
MaRu, w64-ix-slave79 has been set aside for you.
Reporter | ||
Comment 19•11 years ago
|
||
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•11 years ago
|
||
I will run the slave through staging in bug 805553.
![]() |
Assignee | |
Comment 21•11 years ago
|
||
(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 {
![]() |
Assignee | |
Updated•11 years ago
|
Whiteboard: metro-mvp → [metro-mvp][LOE:?]
Reporter | ||
Comment 22•11 years ago
|
||
yeah i can replace asyncinfo.h with a modified version of it.
Updated•11 years ago
|
Reporter | ||
Comment 23•11 years ago
|
||
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•11 years ago
|
||
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.
Reporter | ||
Comment 25•11 years ago
|
||
Thanks for the update. Def. what I wanted to hear :)
![]() |
Assignee | |
Comment 26•11 years ago
|
||
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.
![]() |
Assignee | |
Updated•11 years ago
|
![]() |
Assignee | |
Comment 27•11 years ago
|
||
(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.
![]() |
Assignee | |
Comment 28•11 years ago
|
||
Ok, Elm is now producing testable builds using the new 8.0 SDK and Visual Studio 2010.
![]() |
Assignee | |
Comment 29•11 years ago
|
||
(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.
Summary: Choose/test Windows SDK version → Migrate mozilla build to the Windows 8.0 SDK
Comment 30•11 years ago
|
||
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.
Assignee: mlarrain → armenzg
Updated•11 years ago
|
Assignee: armenzg → server-ops-releng
Comment 31•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 32•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 33•11 years ago
|
||
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•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 35•11 years ago
|
||
Path changes: https://hg.mozilla.org/try/rev/efab8c7ddcd9
![]() |
Assignee | |
Comment 36•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 39•11 years ago
|
||
Assignee: server-ops-releng → jmathies
![]() |
Assignee | |
Updated•11 years ago
|
Component: Server Operations: RelEng → Build Config
Product: mozilla.org → Core
QA Contact: arich
Version: other → Trunk
![]() |
Assignee | |
Comment 40•11 years ago
|
||
(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.
Whiteboard: [metro-mvp][LOE:?] → [metro-mvp][LOE:?][land after next merge: ~2013-01-06]
Comment 41•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
OK, so our test was a little premature.. any other details you want to share before we try again? :)
Comment 48•11 years ago
|
||
(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.
![]() |
Assignee | |
Comment 49•11 years ago
|
||
(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•11 years ago
|
||
(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!
![]() |
Assignee | |
Comment 51•11 years ago
|
||
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.
Attachment #685665 -
Attachment is obsolete: true
Comment 52•11 years ago
|
||
Removing bug 815680 from blocking list as it is more accurate.
No longer blocks: 815680
![]() |
Assignee | |
Updated•11 years ago
|
Whiteboard: [metro-mvp][LOE:?][land after next merge: ~2013-01-06] → [metro-mvp][LOE:-][land after next merge: ~2013-01-06]
![]() |
Assignee | |
Updated•11 years ago
|
Whiteboard: [metro-mvp][LOE:-][land after next merge: ~2013-01-06] → [metro-mvp][LOE:-][land after next merge: ~2013-01-06][metro-it2]
![]() |
Assignee | |
Updated•11 years ago
|
Blocks: enable-metro
![]() |
Assignee | |
Updated•11 years ago
|
Alias: enable-8.0sdk
Comment 53•11 years ago
|
||
I grabbed sdksetup.exe and stashed it in \\releng\data\apps\misc\bug774910 for safe-keeping.
![]() |
Assignee | |
Comment 54•11 years ago
|
||
![]() |
Assignee | |
Comment 55•11 years ago
|
||
- cleaned up comment headers
Attachment #699707 -
Attachment is obsolete: true
![]() |
Assignee | |
Comment 56•11 years ago
|
||
Pushed to try w/the patch in bug 827643 to get good win64 builds - https://tbpl.mozilla.org/?noignore=1&tree=Try&rev=bb40e60527b4
![]() |
Assignee | |
Comment 57•11 years ago
|
||
- removed a couple double colons in INCLUDES
Attachment #699712 -
Attachment is obsolete: true
![]() |
Assignee | |
Comment 58•11 years ago
|
||
full try run including talos: https://tbpl.mozilla.org/?noignore=1&tree=Try&rev=72a4c5fcf318
![]() |
Assignee | |
Comment 59•11 years ago
|
||
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.
Attachment #699753 -
Flags: review?(armenzg)
Comment 60•11 years ago
|
||
Comment on attachment 699753 [details] [diff] [review] 64bit builder mozconfigs LGTM.
Attachment #699753 -
Flags: review?(armenzg) → review+
![]() |
Assignee | |
Updated•11 years ago
|
No longer blocks: enable-metro
![]() |
Assignee | |
Updated•11 years ago
|
![]() |
Assignee | |
Comment 61•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0faa1d47ea80
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [metro-mvp][LOE:-][land after next merge: ~2013-01-06][metro-it2] → [metro-mvp][LOE:-][metro-it2]
Comment 62•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 63•11 years ago
|
||
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.
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•