823109 - Only extract d3d dlls when necessary

Status: REOPENED

(Firefox Build System :: General, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

Attachment: Only extract d3d dlls when necessary

This should be better.

Comment 1

[Joe Drew (not getting mail)]

Try:  https://tbpl.mozilla.org/?tree=Try&rev=b3f3899bc57f

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Only extract d3d dlls when necessary v2

Fix a little mistake that broke the build

Comment 3

[Jeff Muizelaar [:jrmuizel]]

https://tbpl.mozilla.org/?tree=Try&rev=06a01574767b

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 693959 [details] [diff] [review]
Only extract d3d dlls when necessary v2

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

::: gfx/angle/Makefile.in
@@ +133,5 @@
>  endif
>  ifdef MOZ_D3DCOMPILER_CAB
> +libs:: $(DIST)/bin/$(MOZ_D3DCOMPILER_DLL)
> +
> +$(DIST)/bin/$(MOZ_D3DCOMPILER_CAB): $(MOZ_D3DCOMPILER_DLL)

You swapped the CAB and the DLL here, the DLL should be on the left and the CAB on the right.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: With fix

Comment 6

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0d33af2a2a75

Comment 7

[Ed Morley [:emorley]]

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

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Not sure if this is related (or a fix), but after pulling inbound today I was not able anymore to build, got a bunch of errors:

5:02.91 No rule to make target 'C:/Program' needed by ['<command-line>', 'C:/Program']
 5:02.91 No rule to make target 'Files' needed by ['<command-line>', 'Files']
 5:02.91 No rule to make target '(x86)/Microsoft' needed by ['<command-line>', '(x86)/Microsoft']
 5:02.92 No rule to make target 'DirectX' needed by ['<command-line>', 'DirectX']
 5:02.92 No rule to make target 'SDK' needed by ['<command-line>', 'SDK']
 5:02.92 No rule to make target '(June' needed by ['<command-line>', '(June']
 5:02.92 No rule to make target '2010)/Redist/Jun2010_d3dx9_43_x86.cab' needed by ['<command-line>', '2010)/Redist/Jun2010_d3dx9_43_x86.cab']
 5:02.92 <../../dist/bin/D3DCompiler_43.dll>: Found error
 5:02.92 <../../dist/bin/D3DCompiler_43.dll>: Found error
 5:02.92 <../../dist/bin/D3DCompiler_43.dll>: Found error

I tried reinstalling the directx SDK but no luck...
I'm now trying to build with --disable-webgl

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

backed out due to comment 8
https://hg.mozilla.org/mozilla-central/rev/8ea37114e658

now going to merge this back to inbound.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Attachment: Escape possible spaces

Comment 11

[(not currently active) Ted Mielczarek]

Comment on attachment 703968 [details] [diff] [review]
Escape possible spaces

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

This is horrible and I hate make but what can you do?

::: gfx/angle/Makefile.in
@@ +127,5 @@
>  
> +# We use a trick from http://blog.jgc.org/2007/06/escaping-comma-and-space-in-gnu-make.html
> +# to escape possible spaces in MOZ_D3DX9_CAB and MOZ_D3DCOMPILER_CAB
> +space :=
> +space +=

We write this elsewhere as:
space := $(NULL) $(NULL)

but I don't think it matters.

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I'm sorry, still broken, backed out:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed1d3c2794a8

14:17.61 No rule to make target 'C:/Program\' needed by ['<command-line>', 'C:/Program\\']
14:17.61 No rule to make target 'Files\' needed by ['<command-line>', 'Files\\']
14:17.61 No rule to make target '(x86)/Microsoft\' needed by ['<command-line>', '(x86)/Microsoft\\']
14:17.61 No rule to make target 'DirectX\' needed by ['<command-line>', 'DirectX\\']
14:17.61 No rule to make target 'SDK\' needed by ['<command-line>', 'SDK\\']
14:17.61 No rule to make target '(June\' needed by ['<command-line>', '(June\\']
14:17.62 No rule to make target '2010)/Redist/Jun2010_d3dx9_43_x86.cab' needed by ['<command-line>', '2010)/Redist/Jun2010_d3dx9_43_x86.cab']
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 <../../dist/bin/D3DCompiler_43.dll>: Found error
14:17.62 No rule to make target '2010)/Redist/Jun2010_D3DCompiler_43_x86.cab' needed by ['<command-line>', '2010)/Redist/Jun2010_D3DCompiler_43_x86.cab']
14:17.63 <../../dist/bin/d3dx9_43.dll>: Found error

Comment 13

[Dave Townsend [:mossop]]

I also saw the brokenness but only with pymake, regular make seemed to work ok.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

:(

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/65a26453f9a6

Comment 16

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

the backout has not been merged yet.

Comment 17

[[e-mail]]

This approach is doomed to failure.

The .cab file is dated 2nd June 2010.

The .dll file is dated 26th May 2010.

So the rule will always execute.

Comment 18

[[e-mail]]

(In reply to comment #17)
> This approach is doomed to failure.
OK, so I exaggerated slightly.

I don't know whether it's a good idea to change the DLL's timestamp though.

Comment 19

[Bill Gianopoulos [:WG9s]]

(In reply to Dave Townsend (:Mossop) from comment #13)
> I also saw the brokenness but only with pymake, regular make seemed to work
> ok.

Is there a pymake variant behavior bug filed on this?

Comment 21

[Jim Mathies [:jimm]]

pymake is the "official" tool we use for windows builds. So, if pymake works just fine with the old make logic, shouldn't we backout any changes made here and resolve this wontfix?

Comment 22

[Bill Gianopoulos [:WG9s]]

Well probably for now.  But pymake is supposed to work the same way as gnu make, so if it does not then i think a pymake bug should be filed by someone who can understand the issue more than I do.  But yes this has already been backed out.  Just not on mozilla-central yet because no one has done a recent merge from inbound.

Comment 23

[Bill Gianopoulos [:WG9s]]

Should have said this in first comment to avoid bugspam, but resolving WONTFIX is not correct here.  What we need to do is fix this in a way that does not produce regressions.

Comment 24

[Jim Mathies [:jimm]]

oops.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Backout:
https://hg.mozilla.org/mozilla-central/rev/ed1d3c2794a8

Comment 26

[[e-mail]]

Are we actually expecting this DLL to change without its name changing? If not, then can we not generate it without an explicit dependency?

Comment 27

[[e-mail]]

Attachment: Possible patch