c:\t1\hg\comm-central\mozilla\gfx\layers\d3d11\TextureD3D11.h(226) : error C2065: 'D3D_FEATURE_LEVEL_11_1' : undeclared identifier c:\t1\hg\comm-central\mozilla\gfx\layers\d3d11\TextureD3D11.h(226) : error C2051: case expression not constant c:\t1\hg\comm-central\mozilla\gfx\layers\d3d11\TextureD3D11.h(235) : error C2065: 'D3D_FL9_3_REQ_TEXTURE2D_U_OR_V_DIMENSION' : undeclared identifier c:\t1\hg\comm-central\mozilla\gfx\layers\d3d11\TextureD3D11.h(238) : error C2065: 'D3D_FL9_1_REQ_TEXTURE2D_U_OR_V_DIMENSION' : undeclared identifier

Hrm, I thought we were already requiring the new platform SDK for our builds :s.

Oh do I need the Windows 8 SDK?

(In reply to Philip Chee from comment #2) > Oh do I need the Windows 8 SDK? Bas can confirm, but it looks like we landed some work that uses new win8 sdk defines.

This affects Thunderbird as well, but that's because we're still on the win7 sdks. (In reply to Bas Schouten (:bas.schouten) from comment #1) > Hrm, I thought we were already requiring the new platform SDK for our builds > :s. If I'm understanding you right, then I've not seen any notification about requiring to update to Win 8 sdk, and the dev docs still say that Win 7 sdk is acceptable.

We should update the thunderbird config to use the new 8.0 sdk, which should be pretty easy, just a copy of the config files over to comm-central - http://mxr.mozilla.org/comm-central/source/build/win32/ http://mxr.mozilla.org/mozilla-central/source/build/win32/ Independent of this, maybe it's time to require devs use the 8.0 sdk. We'd like to turn metro builds on by default, there's some modified win8 sdk header code in the tree that should be removed, and gfx is now reliant on it. Making this switch should probably involve a post to dev.platform first. So maybe we can come up with a work around for this build problem but get the ball rolling on switching everybody over.

(In reply to Jim Mathies [:jimm] from comment #5) > We should update the thunderbird config to use the new 8.0 sdk, which should > be pretty easy, just a copy of the config files over to comm-central - > > http://mxr.mozilla.org/comm-central/source/build/win32/ > > http://mxr.mozilla.org/mozilla-central/source/build/win32/ > > Independent of this, maybe it's time to require devs use the 8.0 sdk. We'd > like to turn metro builds on by default, there's some modified win8 sdk > header code in the tree that should be removed, and gfx is now reliant on it. > > Making this switch should probably involve a post to dev.platform first. So > maybe we can come up with a work around for this build problem but get the > ball rolling on switching everybody over. Mark is most definitely right, however I'm also very sentimental to jmathies point. Namely because there's no clear advantage to staying on the old SDK to me (the new SDK is free, and we'll need it anyway), and I'd love to avoid any ifdef hell as we had for a long time for D3D10 and Direct2D. If this is impossible I can add some #ifdefing though :).

I have a build in progress with a few ifdefs that allow things to still build using the SDKs we say are the requirement.

For general info, I've separated the TB issues (which include the need for some - unrelated to this bug - builder changes) to bug 869966.

The latest official release of mozillabuild doesn't even recognize the 8.0 SDK. We either need a fix immediately or bug 830347 needs to come out.

Note also that the Windows 8 SDK requires Windows 7 as the minimum system requirements. (VC2010/Win7.1SDK still builds on Windows XP SP3.)

Fixed by backout.

All that said, I did manage to get it all to build with this.

How about shipping some subset of required headers from mingw-w64 project? The trunk version is able to compile all the relevant code that is compiled in non-mentro build. That could be injected by build system by -I... for older Windows SDKs builds, thus would be transparent and #ifdef free. Those headers are normally used by GCC, but are intended to be MSVC-compatible and should not need more than simple adjustments.

> The latest official release of mozillabuild doesn't even recognize the 8.0 SDK. Aargh, you could have told me this before I spent hours trying and failing to get make configure recognize the Windows 8 SDK!!!!!! Also HOW DID BAS MANAGE TO COMPILE HIS PATCH THEN?

By using a prerelease version.

(In reply to Philip Chee from comment #14) > > The latest official release of mozillabuild doesn't even recognize the 8.0 SDK. > Aargh, you could have told me this before I spent hours trying and failing > to get make configure recognize the Windows 8 SDK!!!!!! > > Also HOW DID BAS MANAGE TO COMPILE HIS PATCH THEN? A lot of devs set up their paths manually, myself included. Our startup scripts handle basic setups only. If you have multiple toolchains or tools installed in custom locations manually configuring your paths is the best way to set up your shell.

I know that this whole thing was not intentional to start with. But the overall result of the story that a lot of developer time went wasted. What's the best way to avoid this in the future? Let's say, I want to switch our minimal SDK requirement to SDK 8 on windows, what are the steps to do it properly, causing the minimal pain to all the other developers working on windows? Letting everyone figure it out from build errors is clearly not the way to go. And trying to find a solution on google and on irc is a frustrating experience in the middle of a workflow.

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #17) > I know that this whole thing was not intentional to start with. But the > overall result of the story that a lot of developer time went wasted. What's > the best way to avoid this in the future? Let's say, I want to switch our > minimal SDK requirement to SDK 8 on windows, what are the steps to do it > properly, causing the minimal pain to all the other developers working on > windows? Letting everyone figure it out from build errors is clearly not the > way to go. And trying to find a solution on google and on irc is a > frustrating experience in the middle of a workflow. This is a pretty common occurrence when new sdks come out. Devs tend to switch to the new sdk early and so sometimes some 'new stuff' lands in a patch. Normally these would burn the tree, but in this particular case we had already upgraded our internal builders to the new sdk as well. Typical solution is to back the offending patch out and add fixes to address any missing types or config options that disable new code so that older sdks can remain in use. Maybe omtc should have been ifdef'ed, I'm not sure. Gfx has been going through a lot of changes lately so maybe that wasn't possible. I've posted a missing types fix to the parent bug and will reland as soon as Bas gives the ok.

(In reply to Philip Chee from comment #14) > > The latest official release of mozillabuild doesn't even recognize the 8.0 SDK. > Aargh, you could have told me this before I spent hours trying and failing > to get make configure recognize the Windows 8 SDK!!!!!! > > Also HOW DID BAS MANAGE TO COMPILE HIS PATCH THEN? It works fine with VS2012. Guess what? Our build systems support it just fine. Also, just for the record, using caps doesn't make what you say more valid or more sensible. (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #17) > I know that this whole thing was not intentional to start with. But the > overall result of the story that a lot of developer time went wasted. What's > the best way to avoid this in the future? Let's say, I want to switch our > minimal SDK requirement to SDK 8 on windows, what are the steps to do it > properly, causing the minimal pain to all the other developers working on > windows? Letting everyone figure it out from build errors is clearly not the > way to go. And trying to find a solution on google and on irc is a > frustrating experience in the middle of a workflow. Well, the minimum SDK requirement should just always be what our buildbots have in my mind(i.e. be updated along with our buildbots) :-). That kind of makes the whole problem go away. Because then the build will go red if you depend on anything newer.

(In reply to Bas Schouten (:bas.schouten) from comment #19) > Well, the minimum SDK requirement should just always be what our buildbots I agree.