Only extract d3d dlls when necessary

REOPENED
Assigned to

Status

Firefox Build System
General
REOPENED
6 years ago
4 months ago

People

(Reporter: jrmuizel, Assigned: jrmuizel)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pymake])

Attachments

(2 attachments, 3 obsolete attachments)

Created attachment 693931 [details] [diff] [review]
Only extract d3d dlls when necessary

This should be better.
Attachment #693931 - Flags: review?(gps)
Created attachment 693959 [details] [diff] [review]
Only extract d3d dlls when necessary v2

Fix a little mistake that broke the build
Attachment #693931 - Attachment is obsolete: true
Attachment #693931 - Flags: review?(gps)
Attachment #693959 - Flags: review?(gps)
Attachment #693959 - Flags: review?(gps) → review?(ted)
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.
Attachment #693959 - Flags: review?(ted) → review-
Created attachment 699375 [details] [diff] [review]
With fix
Attachment #693959 - Attachment is obsolete: true
Attachment #699375 - Flags: review?(ted)
Attachment #699375 - Flags: review?(ted) → review+
Assignee: nobody → jmuizelaar

Comment 7

6 years ago
https://hg.mozilla.org/mozilla-central/rev/0d33af2a2a75
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
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
backed out due to comment 8
https://hg.mozilla.org/mozilla-central/rev/8ea37114e658

now going to merge this back to inbound.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 703968 [details] [diff] [review]
Escape possible spaces
Attachment #699375 - Attachment is obsolete: true
Attachment #703968 - Flags: review?(ted)
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.
Attachment #703968 - Flags: review?(ted) → review+
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
I also saw the brokenness but only with pymake, regular make seemed to work ok.
https://hg.mozilla.org/mozilla-central/rev/65a26453f9a6
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
the backout has not been merged yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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.
(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?
Depends on: 834845

Updated

6 years ago
Duplicate of this bug: 834845

Updated

6 years ago
No longer depends on: 834845
Depends on: 834845

Comment 21

6 years ago
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?
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.
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.

Updated

6 years ago
Component: Build Config → Permission Manager
Whiteboard: [pymake]

Comment 24

6 years ago
oops.
Component: Permission Manager → Build Config
Backout:
https://hg.mozilla.org/mozilla-central/rev/ed1d3c2794a8
Target Milestone: mozilla21 → ---
Are we actually expecting this DLL to change without its name changing? If not, then can we not generate it without an explicit dependency?

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.