Closed Bug 643732 Opened 14 years ago Closed 14 years ago

DirectX SDK not detected on WinXP

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: swsnyder, Assigned: joe)

References

Details

Attachments

(1 file, 1 obsolete file)

get MOZ_DIRECTX_SDK_PATH from Environment variable DXSDK_DIR
1.17 KB, patch
Details | Diff | Splinter Review
The configure script does not correctly extract the DirectX SDK path from the Windows registry. The string parsed-out from the registry is incorrect, leading to failed files tests when configure / configure.in is run. This is the existing code: $ export MOZ_DIRECTX_SDK_REG_KEY=`reg query 'HKLM\Software\Microsoft\DirectX' //s | grep 'Microsoft DirectX SDK' | head -n 1` $ echo $MOZ_DIRECTX_SDK_REG_KEY HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) So far, so good. The next line is the problem: $ export MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's, *, ,g' | cut -d' ' -f4-` $ echo $MOZ_DIRECTX_SDK_PATH DirectX SDK (June 2010) That "DirectX SDK (June 2010)" is not a path, it's a fragment of a path. Below is what works. Note the modified 'cut' command: $ export MOZ_DIRECTX_SDK_PATH=`reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's, *, ,g' | cut -f3-` $ echo $MOZ_DIRECTX_SDK_PATH C:\Program Files\Microsoft DirectX SDK (June 2010) The result of the erroneous parsing of the path is that the test of the header and library files that rely on the correct path failed, disallowing MOZ_ANGLE in the build.
Have I mentioned how much I want to move this all to MozillaBuild? configure should not have to dig around in the registry.
I'm not submitting a patch for this trivial fix because I assume that the existing detection works for some Windows environments. For mine, it does not. Environment: WinXP Prof./SP3 (x86) with all updates applied Visual Studio Prof. 2008/SP1 plus security fixes Windows SDK v7.1 (x86) DirectX SDK, June 2010 MozillaBuild v1.5.1 + WinSDK v7.1 patch Seen with Firefox 4.0 RC2 tarball.
@ Steve: Can you paste the output of: reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath @ Ted: I agree, we should have that in MozillaBuild. Vlad wasn't in favor of that because we don't put the other Windows SDKs in MozillaBuild, but since we only need a few files and they're causing trouble, it seems justified to me.
(In reply to comment #3) > @ Steve: > > Can you paste the output of: > reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath $ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath ! REG.EXE VERSION 3.0 HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) InstallPath REG_SZ C:\Program Files\Microsoft DirectX SDK (June 2010)
Attached patch fix (obsolete) — — Splinter Review
Assignee: nobody → joe
Attachment #522429 - Flags: review?(ted.mielczarek)
The problem is that reg.exe outputs tabs, not spaces, so I've substituted the sed for two trs - one to squeeze spaces together, another to substitute spaces for tabs.
(In reply to comment #5) > Created attachment 522429 [details] [diff] [review] > fix The proposed fix doesn't work for 64-bit installations: $ export MOZ_DIRECTX_SDK_REG_KEY=`reg query 'HKLM\Software\Microsoft\DirectX' //s | grep 'Microsoft DirectX SDK' | head -n 1` $ echo $MOZ_DIRECTX_SDK_REG_KEY HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) $ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | tr -s ' ' | tr "\t" " " | cut -d' ' -f4 C:\Program The original code parses correctly: $ reg query "$MOZ_DIRECTX_SDK_REG_KEY" //v InstallPath | grep REG_SZ | sed 's, *, ,g' | cut -d' ' -f4- C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)
We only use the DirectX SDK for ANGLE right now, which isn't supported on 64-bit, so this isn't the end of the world.
Oh wait - I understand. Doesn't work on a 64-bit OS while building 32-bit programs. I can fix that.
Comment on attachment 522429 [details] [diff] [review] fix Well, crap. I'm going to have to think harder about this.
Attachment #522429 - Attachment is obsolete: true
Attachment #522429 - Flags: review?(ted.mielczarek)
I coped the code from your attachment into a new shell script. The results are below. WinXP x64: $ echo $MOZ_DIRECTX_SDK_REG_KEY HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) $ /n/GetDXSDK.sh MOZ_DIRECTX_SDK_REG_KEY=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) MOZ_DIRECTX_SDK_PATH= InstallPath REG_SZ C:\Program Files (x86)\Microsoft DirectX SDK (June 2010) WinXP x86 --------- $ echo $MOZ_DIRECTX_SDK_REG_KEY HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) $ /n/GetDXSDK.sh MOZ_DIRECTX_SDK_REG_KEY=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\Microsoft DirectX SDK (June 2010) MOZ_DIRECTX_SDK_PATH= InstallPath REG_SZ C:\Program Files\Microsoft DirectX SDK (June 2010) The good news: the correct path is found in both environments. The bad news: some further clean-up is needed to remove the extraneous leading text in both cases.
(In reply to comment #12) > I coped the code from your attachment into a new shell script. The results > are below. You can't do that :-) the code in my attachment is using m4 escaping of square brackets, at least. You would at least have to replace [[x]] by [x]. (In reply to comment #13) > Created attachment 531029 [details] [diff] [review] [review] > get MOZ_DIRECTX_SDK_PATH from Environment variable DXSDK_DIR If we do that, then we should do that only as a fallback if getting it from the registry didn't work. We want to be able to list the different DirectX SDKs installed and prefer the June 2010 SDK over other versions. See patch from comment 11.
Well, the code I submitted as a patch for bug 656055 leaves things working as they do just fixes the issue of Windows/XP using Tabs rather than spaces as delimiters. Not sure if that is preferable to what is being proposed here or not.
This issue is fixed by the pending patch in bug 648804.
(In reply to comment #16) > Well, the code I submitted as a patch for bug 656055 leaves things working > as they do just fixes the issue of Windows/XP using Tabs rather than spaces > as delimiters. Not sure if that is preferable to what is being proposed > here or not. I decided I like the patch in bug 648804 better. My patch in bug 656055 just kind of made a kludge more kludgey .
Oh! Joe just tried my patch in bug 648804 on WinXP and said it didn't work. What give?
(In reply to comment #19) > Oh! Joe just tried my patch in bug 648804 on WinXP and said it didn't work. > What give? I don't get it. It seems to work for me, once I replaced the DOS line endings with UNIX line endings. ('\r\n' to \'n') One would think Joe would have gotten past that. But this works fine for me under Windows/XP, so I don't get it either.
I'm using the February 2010 DX SDK; I will retest tomorrow with the patch as-is, but running the commands from the patch manually didn't seem to work.
(In reply to comment #21) > I'm using the February 2010 DX SDK; I will retest tomorrow with the patch > as-is, but running the commands from the patch manually didn't seem to work. Oh :-) You can't just copy and paste the commands from the patch into bash, because they are m4-escaped: [a-z] becomes [[a-z]] (In reply to comment #20) > I don't get it. It seems to work for me, once I replaced the DOS line > endings with UNIX line endings. ('\r\n' to \'n') Oops. Definitely configure.in needs UNIX line endings. Sorry about that.
Fixed by http://hg.mozilla.org/mozilla-central/rev/962fee06b08e from bug 648804
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: