Closed Bug 980697 Opened 6 years ago Closed 6 years ago

Pull newer versions of the d3dcompiler dll from installed Windows SDKs

Categories

(Core :: Canvas: WebGL, defect)

All
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: jgilbert, Assigned: jgilbert)

References

Details

(Whiteboard: webgl-internal)

Attachments

(4 files, 3 obsolete files)

[Previously bug 896762]

Switching to the newer Win8 and Win8.1 Windows SDKs gives us access to d3dcompiler_46 and _47.dll respectively. We should update our build scripts to be able to pull in these newer types.

We should consider dropping support for older versions of the compiler. There are definite reasons we want the newer DLL as opposed to the old one.

I believe we should make _46 the minimum. and remove support for the older DirectX SDK source-location.
Summary: Use newer versions of the d3dcompiler dll if available → Pull newer versions of the d3dcompiler dll from installed Windows SDKs
See Also: → 896762
Not "We should consider dropping support for older versions of the compiler.", but "We should drop support for older versions of the compiler, less than d3dcompiler_46.dll."
Comment on attachment 8387289 [details] [diff] [review]
(from h.rayflood) patch 1: use windows sdk for directx headers and libraries

Review of attachment 8387289 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +5694,5 @@
>  dnl = * enabled by default (shipping build); requires explicit --disable to disable
>  dnl ========================================================
>  MOZ_ANGLE_RENDERER=
>  MOZ_DIRECTX_SDK_PATH=
> +MOZ_WINSDK_DIRECTX=

This seems like it should be called MOZ_HAS_WINSDK_WITH_D3D.

@@ +5737,5 @@
> +  case "$MOZ_WINSDK_MAXVER" in
> +  0x0603*)
> +    MOZ_WINSDK_DIRECTX=1
> +    MOZ_D3DX9_VERSION=47
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_$MOZ_D3DX9_VERSION.dll

Don't use MOZ_D3DX9_VERSION here anymore, since it's only relevant to old DX SDK stuff.
Remove the MOZ_D3DX9_VERSION line and set the MOZ_D3DCOMPILER_DLL line explicitly.

Also, the filenames are not uppercase. The files in both the 8.0 and 8.1 SDKs are named "d3dcompiler_NN.dll", where NN is 46 and 47 respective to the versions.

@@ +5762,5 @@
>    fi
>    MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's/.*\([[a-zA-Z]]\)\\:\\\\/\\1\\:\\\\/' | sed 's,\\\\,/,g'`
>  fi
>  
> +if test -n "$MOZ_ANGLE_RENDERER" -a -z "$CROSS_COMPILE" -a -z "$MOZ_WINSDK_DIRECTX"; then

I hate if/test syntax so much.

@@ +5825,5 @@
>          elif test "$GCC" != "yes"; then
>              MOZ_GAMEPAD=
>          fi
> +        if test -n "$MOZ_WINSDK_DIRECTX"; then
> +            MOZ_GAMEPAD=1

Why is this added here? This seems like it should go in a dependent bug.

::: gfx/angle/Makefile.in
@@ +4,5 @@
>  
>  ifdef MOZ_ANGLE_RENDERER
>  
>  libs::
> +ifndef MOZ_WINSDK_DIRECTX

Prefer ifdef to ifndef in this case. Switch the order here, since we want to (eventually) deprecate usage of the DX SDK. [1]

@@ +9,5 @@
>  ifdef MOZ_D3DCOMPILER_CAB
>  	expand '$(MOZ_D3DCOMPILER_CAB)' -F:$(MOZ_D3DCOMPILER_DLL) '$(DIST)/bin'
>  endif
> +else
> +	cp -p "$${WINDOWSSDKDIR}/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

Why $${WINDOWSSDKDIR} instead of $(WINDOWSSDKDIR)?

::: gfx/angle/src/libEGL/Makefile.in
@@ +20,1 @@
>  CXXFLAGS += -I'$(MOZ_DIRECTX_SDK_PATH)/include'

Do we really need this anymore, if it's already in config.mk?

@@ +28,5 @@
>  OS_LIBS += -ld3d9 -llibGLESv2
>  
>  else
>  
> +ifndef MOZ_WINSDK_DIRECTX

[1]

::: gfx/angle/src/libGLESv2/Makefile.in
@@ +27,5 @@
>  OS_LIBS += -ld3d9 -ldxguid
>  
>  else
>  
> +ifndef MOZ_WINSDK_DIRECTX

[1]

::: toolkit/library/Makefile.in
@@ +110,5 @@
>  EXTRA_DSO_LDOPTS += $(call EXPAND_LIBNAME_PATH,gkmedias,$(DIST)/lib)
>  
>  ifdef MOZ_WEBRTC
>  ifeq (WINNT,$(OS_TARGET))
> +ifndef MOZ_WINSDK_DIRECTX

[1]

@@ +243,5 @@
>  OS_LIBS += $(call EXPAND_LIBNAME,uiautomationcore runtimeobject)
>  endif
>  ifdef MOZ_GAMEPAD
>  ifndef GNU_CC
> +ifndef MOZ_WINSDK_DIRECTX

[1]
Attachment #8387289 - Flags: review?(jgilbert) → review-
Flags: needinfo?(h.rayflood)
(In reply to Dan Glastonbury :djg :kamidphish from comment #2)
> Not "We should consider dropping support for older versions of the
> compiler.", but "We should drop support for older versions of the compiler,
> less than d3dcompiler_46.dll."

Sure, that's a good step. We really want to always use the same one, though, so eventually, we should wean people off 8.0 and onto 8.1 SDK.
Whiteboard: webgl-internal
Dropping d3dcompiler_43 support means dropping Win7 SDK support because d3dcompiler > 46 is bundled with Win SDL > 8.0 and no standalone DXSDK is available anymore.
According to the MDN doc, We are supposed to support Win7 SDK.
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites
Although I don't disagree with dropping support for Win7 SDK, it should be announced somewhere, at least.

(In reply to Jeff Gilbert [:jgilbert] from comment #4)
> so eventually, we should wean people off 8.0 and onto 8.1 SDK.

Please update our infra first :) The tbpl is using Win8.0 SDK.
Attachment #8387562 - Flags: review?(jgilbert)
Flags: needinfo?(h.rayflood)
thanks for your review.

(In reply to Jeff Gilbert [:jgilbert] from comment #3)
> Comment on attachment 8387289 [details] [diff] [review]
> (from h.rayflood) patch 1: use windows sdk for directx headers and libraries
> 
> Review of attachment 8387289 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/angle/src/libEGL/Makefile.in
> @@ +20,1 @@
> >  CXXFLAGS += -I'$(MOZ_DIRECTX_SDK_PATH)/include'
> 
> Do we really need this anymore, if it's already in config.mk?
> 
-I'$(MOZ_DIRECTX_SDK_PATH)/include' in config.mk is not worked.
we need -I'$(MOZ_DIRECTX_SDK_PATH)/include' in libEGL/Makefile.in and libGLESv2/Makefile.in
Attachment #8387289 - Attachment is obsolete: true
Comment on attachment 8387562 [details] [diff] [review]
patch1 rev2: use windows sdk for directx headers and libraries

Review of attachment 8387562 [details] [diff] [review]:
-----------------------------------------------------------------

One more time!

::: configure.in
@@ +5759,5 @@
> +if test -n "$MOZ_ANGLE_RENDERER" -a -z "$CROSS_COMPILE"; then
> +  case "$MOZ_WINSDK_MAXVER" in
> +  0x0603*)
> +    MOZ_HAS_WINSDK_WITH_D3D=1
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_47.dll

"d3dcompiler_47" should be all lower-case.

@@ +5764,5 @@
> +    AC_MSG_RESULT([Found DirectX SDK in Windows SDK 8.1 .])
> +  ;;
> +  0x0602*)
> +    MOZ_HAS_WINSDK_WITH_D3D=1
> +    MOZ_D3DCOMPILER_DLL=D3DCompiler_46.dll

"d3dcompiler_46" should be all lower-case.

::: gfx/angle/Makefile.in
@@ +5,5 @@
>  ifdef MOZ_ANGLE_RENDERER
>  
>  libs::
> +ifdef MOZ_HAS_WINSDK_WITH_D3D
> +	cp -p "$(WINDOWSSDKDIR)/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

-fp for --force and --preserve
Attachment #8387562 - Flags: review?(jgilbert) → review-
Attachment #8387569 - Flags: review?(jgilbert) → review+
(In reply to Jeff Gilbert [:jgilbert] from comment #9)
> Comment on attachment 8387562 [details] [diff] [review]
> patch1 rev2: use windows sdk for directx headers and libraries
> 
> Review of attachment 8387562 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> One more time!
> 
thanks. I did it!
Attachment #8387562 - Attachment is obsolete: true
Attachment #8388015 - Flags: review?(jgilbert)
Attachment #8388015 - Flags: review?(jgilbert) → review+
Cool, thanks.
Comment on attachment 8388015 [details] [diff] [review]
patch1 rev3: use windows sdk for directx headers and libraries

Let's get review from a build peer.
Attachment #8388015 - Flags: review?(gps)
Comment on attachment 8387569 [details] [diff] [review]
patch2: mozilla-build: overwrite WINDOWSSDKDIR to windows sdk 8.0 or 8.1 on msvc2010

Let's get review from a build peer.
Attachment #8387569 - Flags: review?(gps)
Comment on attachment 8387569 [details] [diff] [review]
patch2: mozilla-build: overwrite WINDOWSSDKDIR to windows sdk 8.0 or 8.1 on msvc2010

This part looks fine.
Attachment #8387569 - Flags: review?(gps) → review+
Comment on attachment 8388015 [details] [diff] [review]
patch1 rev3: use windows sdk for directx headers and libraries

>diff --git a/gfx/angle/Makefile.in b/gfx/angle/Makefile.in
>--- a/gfx/angle/Makefile.in
>+++ b/gfx/angle/Makefile.in
>@@ -1,18 +1,22 @@
> # This Source Code Form is subject to the terms of the Mozilla Public
> # License, v. 2.0. If a copy of the MPL was not distributed with this
> # file, You can obtain one at http://mozilla.org/MPL/2.0/.
> 
> ifdef MOZ_ANGLE_RENDERER
> 
> libs::
>+ifdef MOZ_HAS_WINSDK_WITH_D3D
>+	cp -fp "$(WINDOWSSDKDIR)/Redist/D3D/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)/$(MOZ_D3DCOMPILER_DLL)" "$(DIST)/bin"

Relying on WINDOWSSDKDIR to be set in the environment here makes me nervous. If it happens to not be set, or the environment changes for whatever reason, this will do the wrong thing. I think we should AC_SUBST(WINDOWSSDKDIR) from configure (perhaps erroring out if it isn't set when MOZ_HAS_WINSDK_WITH_D3D is true).
Attachment #8388015 - Flags: review?(gps) → feedback+
We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL, MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of trying to construct a path in the angle Makefile.in?
Comment on attachment 8389637 [details] [diff] [review]
patch1 rev4: use windows sdk for directx headers and libraries

Thanks for changing that - looks good!
Attachment #8389637 - Flags: review?(mshal) → review+
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> trying to construct a path in the angle Makefile.in?

In one case, we need to pull it out of a CAB, and in the other, it's just a straight copy across.
https://tbpl.mozilla.org/?tree=Try&rev=2abd7ce2db8c

I'm testing a build locally to be sure we pull the newer of the choices.
(In reply to Jeff Gilbert [:jgilbert] from comment #20)
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> > We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> > MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> > MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> > trying to construct a path in the angle Makefile.in?
> 
> In one case, we need to pull it out of a CAB, and in the other, it's just a
> straight copy across.

Don't care about the CAB version any more.  Just skip copying a d3d compiler DLL in that case, ideally warn that they need to upgrade their SDK.  But we can clean this up afterwards.  The build machines all have the right (8.x) SDK, so it's only individual developers that need to update.  And if they're doing any webgl-related work, they likely have a newer SDK anyway, or can update easily.

Just make sure to update the windows build prereqs page.
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #22)
> (In reply to Jeff Gilbert [:jgilbert] from comment #20)
> > (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #16)
> > > We do a lot of work in configure.in to figure out MOZ_D3DCOMPILER_DLL,
> > > MOZ_DIRECTX_SDK_PATH, etc.   Why don't we just condense all of that into
> > > MOZ_D3DCOMPILER_DLL_PATH, and copy "$(MOZ_D3DCOMPILER_DLL_PATH)" instead of
> > > trying to construct a path in the angle Makefile.in?
> > 
> > In one case, we need to pull it out of a CAB, and in the other, it's just a
> > straight copy across.
> 
> Don't care about the CAB version any more.  Just skip copying a d3d compiler
> DLL in that case, ideally warn that they need to upgrade their SDK.  But we
> can clean this up afterwards.  The build machines all have the right (8.x)
> SDK, so it's only individual developers that need to update.  And if they're
> doing any webgl-related work, they likely have a newer SDK anyway, or can
> update easily.
> 
> Just make sure to update the windows build prereqs page.

Alright, let's do that in a follow-up, so as not to slow this down.
Yep, local clobber pulls in _47.dll for me. :)
Try is not happy:

make.py[5]: Entering directory 'c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle'
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle\Makefile:16:0$ cp -fp "/Redist/D3D/x86/d3dcompiler_46.dll" "../../dist/bin"
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\makefiles\autotargets.mk:59:0$ pymake.builtins mkdir -p '.deps/'
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\obj-firefox\gfx\angle\Makefile:16:0: command 'cp -fp "/Redist/D3D/x86/d3dcompiler_46.dll" "../../dist/bin"' failed, return code 1
cp: cannot stat `/Redist/D3D/x86/d3dcompiler_46.dll': No such file or directory
evaluation from c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\recurse.mk:189:53:14:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -C angle libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\recurse.mk:162:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -C gfx libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\config\rules.mk:599:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py libs' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\client.mk:398:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -j4 -C obj-firefox' failed, return code 2
c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\client.mk:185:0: command 'C:/mozilla-build/python27/python.exe c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/build/pymake/pymake/../make.py -f c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/client.mk realbuild' failed, return code 2
program finished with exit code 2
Comment on attachment 8389637 [details] [diff] [review]
patch1 rev4: use windows sdk for directx headers and libraries

Review of attachment 8389637 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +5772,5 @@
> +  esac
> +fi
> +
> +if test -n "$MOZ_HAS_WINSDK_WITH_D3D"; then
> +  MOZ_D3DCOMPILER_DLL_PATH="$WINDOWSSDKDIR/Redist/D3D/$MOZ_DIRECTX_SDK_CPU_SUFFIX"

We should require $WINDOWSSDKDIR to not be null in order to set MOZ_HAS_WINSDK_WITH_D3D=1.
There is no WINDOWSSDKDIR in the environment on Try:

environment:
  ALLUSERSPROFILE=C:\ProgramData
  APPDATA=C:\Users\cltbld\AppData\Roaming
  APR_ICONV_PATH=c:/mozilla-build/svn-win32-1.6.3/iconv
  BINSCOPE=C:\Program Files (x86)\Microsoft\SDL BinScope\BinScope.exe
  COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
  COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
  COMMONPROGRAMW6432=C:\Program Files\Common Files
  COMPUTERNAME=W64-IX-SLAVE57
  COMSPEC=C:\windows\system32\cmd.exe
  CVS_RSH=ssh
  DXSDK_DIR=C:\Tools\sdks\dx10\
  EDITOR=emacs.exe --no-window-system
  FP_NO_HOST_CHECK=NO
  HG_SHARE_BASE_DIR=c:/builds/hg-shared
  HOME=c:/Users/cltbld
  HOMEDRIVE=C:
  HOMEPATH=\
  HOSTTYPE=i686
  INPUTRC=C:/mozilla-build/msys/etc/inputrc
  KTS_HOME=C:\Program Files\KTS
  KTS_VERSION=1.19c
  LOCALAPPDATA=C:\Users\cltbld\AppData\Local
  LOG="c:\tmp\buildbot-startup.log"
  LOGNAME=cltbld
  LOGONSERVER=\\W64-IX-SLAVE57
  MACHTYPE=i686-pc-msys
  MAKE_MODE=unix
  MOZBUILDDIR=C:\mozilla-build\
  MOZILLABUILD=C:\mozilla-build\
  MOZ_CRASHREPORTER_NO_REPORT=1
  MOZ_OBJDIR=obj-firefox
  MOZ_SIGN_CMD=python c:/builds/moz2_slave/try-w32-d-00000000000000000000/tools/release/signing/signtool.py --cachedir c:/builds/moz2_slave/try-w32-d-00000000000000000000/signing_cache -t c:/builds/moz2_slave/try-w32-d-00000000000000000000/token -n c:/builds/moz2_slave/try-w32-d-00000000000000000000/nonce -c c:/builds/moz2_slave/try-w32-d-00000000000000000000/tools/release/signing/host.cert -H signing4.srv.releng.scl3.mozilla.com:9110 -H signing5.srv.releng.scl3.mozilla.com:9110 -H signing6.srv.releng.scl3.mozilla.com:9110
  MOZ_TOOLS=C:\mozilla-build\\moztools-x64
  MSYSTEM=MINGW32
  NUMBER_OF_PROCESSORS=4
  OLDPWD=c:/Users/cltbld
  OS=Windows_NT
  OSTYPE=msys
  PATH=C:\mozilla-build\nsis-2.46u;C:\mozilla-build\python27;C:\mozilla-build\buildbotve\scripts;C:\mozilla-build\msys\local\bin;c:\mozilla-build\wget;c:\mozilla-build\7zip;c:\mozilla-build\blat261\full;c:\mozilla-build\python;c:\mozilla-build\svn-win32-1.6.3\bin;c:\mozilla-build\upx203w;c:\mozilla-build\emacs-22.3\bin;c:\mozilla-build\info-zip;c:\mozilla-build\nsis-2.22;c:\mozilla-build\nsis-2.33u;c:\mozilla-build\nsis-2.46u;c:\mozilla-build\wix-351728;c:\mozilla-build\hg;c:\mozilla-build\python\Scripts;c:\mozilla-build\kdiff3;c:\mozilla-build\yasm;.;C:\mozilla-build\msys\local\bin;C:\mozilla-build\msys\mingw\bin;C:\mozilla-build\msys\bin;c:\windows\system32;c:\windows;c:\windows\System32\Wbem;c:\windows\System32\WindowsPowerShell\v1.0\;c:\mozilla-build;c:\mozilla-build\python27;c:\mozilla-build\python27\Scripts;C:\mozilla-build\msys\bin;c:\mozilla-build\vim\vim72;c:\mozilla-build\wget;c:\mozilla-build\info-zip;c:\CoreUtils\bin;c:\mozilla-build\buildbotve\scripts;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;c:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\;c:\mozilla-build\moztools-x64\bin;c:\mozilla-build\vim\vim72
  PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
  PROCESSOR_ARCHITECTURE=x86
  PROCESSOR_ARCHITEW6432=AMD64
  PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel
  PROCESSOR_LEVEL=6
  PROCESSOR_REVISION=1e05
  PROGRAMDATA=C:\ProgramData
  PROGRAMFILES=C:\Program Files (x86)
  PROGRAMFILES(X86)=C:\Program Files (x86)
  PROGRAMW6432=C:\Program Files
  PROMPT=$P$G
  PS1=\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ 
  PSMODULEPATH=C:\windows\system32\WindowsPowerShell\v1.0\Modules\
  PUBLIC=C:\Users\Public
  PWD=c:/Users/cltbld
  SHELL=C:/mozilla-build/msys/bin/sh
  SHLVL=1
  SSH_AGENT_PID=2872
  SSH_AUTH_SOCK=C:/Users/cltbld/AppData/Local/Temp/ssh-fYsewp2604/agent.2604
  SYSTEMDRIVE=C:
  SYSTEMROOT=C:\windows
  TEMP=C:/Users/cltbld/AppData/Local/Temp
  TERM=cygwin
  TMP=C:/Users/cltbld/AppData/Local/Temp
  USERDOMAIN=W64-IX-SLAVE57
  USERNAME=cltbld
  USERPROFILE=C:\Users\cltbld
  VS100COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
  WINDIR=C:\windows
  WINDOWS_TRACING_FLAGS=3
  WINDOWS_TRACING_LOGFILE=C:\BVTBin\Tests\installpackage\csilogfile.log
  WIX_351728_PATH=c:/mozilla-build/wix-351728
  XPCOM_DEBUG_BREAK=stack-and-abort
  _=c:/mozilla-build/python/python
I'm looking at falling back to building the WinSDK path from $PROGRAMFILES.
Attachment #8390143 - Flags: review?(vladimir)
Attachment #8390143 - Flags: review?(mshal)
Comment on attachment 8390143 [details] [diff] [review]
patch 3: Update and reorg the ANGLE-related configure code

Review of attachment 8390143 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me.  Let's just kill off the 2010 SDK support after this gecko ships (so, like, next week) and clean up a bunch of this?
Attachment #8390143 - Flags: review?(vladimir) → review+
Depends on: 982973
Attachment #8390143 - Flags: review?(mshal) → review+
ANGLE isn't creating contexts on XP:
https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c

Are we sure _46 still supports XP?
(In reply to Jeff Gilbert [:jgilbert PTO through Mar26] from comment #31)
> ANGLE isn't creating contexts on XP:
> https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c
> 
> Are we sure _46 still supports XP?

According to <http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx>, it doesn't anymore :(
> The actual D3DCompiler_*.DLL in the Windows 8.0 SDK itself only supports
> Windows Vista, Windows 7, and Windows 8.
(snip)
> Note: you can select a Platform Toolset of "v100-sdk80" with the Windows
> 8.0 SDK and Visual Studio 2010 installed to get the VS 2010 compiler
> toolset but using the newer Windows 8.0 SDK header set, but remember
> that version of D3DCompiler_*.DLL does not support runtime use or
> deployment on Windows XP.
So we will have to make MOZ_HAS_WINSDK_WITH_D3D a configurable option. Of course we can't remove _43 support until we drop support for Windows XP :(
This is still useful for local builds.
Also fixed a bug in the previous patch.

Try run: https://tbpl.mozilla.org/?tree=Try&rev=bc2321f4baec
Attachment #8394839 - Flags: review?(mshal)
Comment on attachment 8394839 [details] [diff] [review]
Make Direct X SDK in Windows SDK opt-in

Looks good to me!
Attachment #8394839 - Flags: review?(mshal) → review+
Folded three patches so that bisecting isn't confused.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf2974b3e42e
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/cf2974b3e42e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
(In reply to Jeff Gilbert [:jgilbert PTO through Mar26] from comment #31)
> ANGLE isn't creating contexts on XP:
> https://tbpl.mozilla.org/?tree=Try&rev=f141fc789e7c
> 
> Are we sure _46 still supports XP?

Dan tested it, the DLLs work fine.  Maybe there's something that's missing, but we should find that out in testing..
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #39)
> Dan tested it, the DLLs work fine.  Maybe there's something that's missing,
> but we should find that out in testing..

It contradicts with my testing...
D3DCompiler_47.dll has the subsystem version 6.0 in the PE header, so it can't work with WinXP. Rather Dan must have missed something.
Can you try modifying d3dcompiler_47.dll using editbin, e.g. "editbin /subsystem:WINDOWS,5.01 d3dcompiler_47.dll" and see if it works?  Just to see if there's an actual issue, or just the headers.
Even if it technically works, is it legally allowed?
I would not like to file yet another bug to use this bug for hacking around the copyrighted dll.
The DLL depends on a Vista-only function (_except_handler4_common) anyway.
Please leave any legal decisions to us, and limit this and other bugs to just technical discussions.  Let's figure out *if* it works, and then we can figure out what to do about that result. .. but it sounds like it doesn't, hrm.  That's a huge pain, since we might end up needing to ship both.  Will figure it out.
Depends on: 988271
Please check in patch2 to mozilla-build.
Oops, missed the MozillaBuild 1.9.0 release, sorry :(
https://hg.mozilla.org/mozilla-build/rev/af43db058d60
MozillaBuild 1.9.0 has not been staged:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/

See https://bugzilla.mozilla.org/show_bug.cgi?id=989312

(In reply to Masatoshi Kimura [:emk] from comment #47)
> Oops, missed the MozillaBuild 1.9.0 release, sorry :(
> https://hg.mozilla.org/mozilla-build/rev/af43db058d60
But sources are already tagged. Can we respin the release?
Yes, please respin the release. 
Awaiting, further confirmation.

(In reply to Masatoshi Kimura [:emk] from comment #49)
> But sources are already tagged. Can we respin the release?
Any particular reason nobody felt the need to bring this to my attention earlier? The release is tagged and the tracking bug made it quite clear that release is imminent.
Oversight, I assume.  Sorry!  Upside of taking it is that it removes a painful build dependency for (new) Windows developers.
One heck of an oversight to not mark any dependencies or even CC the current package maintainer to a bug filed in a different component about something that you want crammed in at the last second. On 3/25, I posted a note in bug 928594 that I wanted to release by the end of the week. I posted a release candidate on 3/26. After receiving no feedback or indication that something else was still wanted (and there are plenty of people CCed to that bug that are also involved in this one), I tagged it for release on 3/28. How much more time do I need to give people to chime in so I can avoid the "WAIT ONE MORE THING!" comments that even have any sort of validity due to RelEng not getting around to finishing their bug yet.
Blocks: 999260
Depends on: 1061084
No longer depends on: 1061084
You need to log in before you can comment on or make changes to this bug.