Bug 111504 – build a DumpRenderTree.pak even on windows

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Dirk Pranke]

build a DumpRenderTree.pak even on windows

[Dirk Pranke]

Created attachment 191620 [details]
Patch

[Dirk Pranke]

Comment on attachment 191620 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=191620&action=review

> Tools/DumpRenderTree/DumpRenderTree.gyp/DumpRenderTree.gyp:-345
> -                    }],

I don't know why we were previously building the .pak file in <(INTERMEDIATE_DIR) and then copying it into <(PRODUCT_DIR). Is there a reason not to just build it into <(PRODUCT_DIR) by default?

[Tony Chang]

Comment on attachment 191620 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=191620&action=review

>> Tools/DumpRenderTree/DumpRenderTree.gyp/DumpRenderTree.gyp:-345
>> -                    }],
> 
> I don't know why we were previously building the .pak file in <(INTERMEDIATE_DIR) and then copying it into <(PRODUCT_DIR). Is there a reason not to just build it into <(PRODUCT_DIR) by default?

Not sure, but it seems fine to write the final result to <(PRODUCT_DIR).

[Dirk Pranke]

Comment on attachment 191620 [details]
Patch

Clearing flags on attachment: 191620

Committed r144863: <http://trac.webkit.org/changeset/144863>

[Dirk Pranke]

All reviewed patches have been landed.  Closing bug.

[Dirk Pranke]

hm, this appears to break xcode ... making DumpRenderTree_resources be a separate target and still having process_outputs_as_mac_bundle_resources set to true doesn't look like it works right (since DumpRenderTree_resources isn't actually a bundle).

Temporarily, I'm going to set that flag off, and we'll see what else breaks.

[Dirk Pranke]

Okay, I've attempted to patch this in bug 111506 / r144866 . It looks like that might work, but I have to wait for the xcode builders to cycle to be sure, and even then I'm not sure if this is the right fix.

[Dirk Pranke]

Er, that's bug 111509, not bug 111506.

[Nico Weber]

(In reply to comment #7)
> Okay, I've attempted to patch this in bug 111506 / r144866 . It looks like that might work, but I have to wait for the xcode builders to cycle to be sure, and even then I'm not sure if this is the right fix.

It fairly likely isn't. I commented on bug 111509.

[Nico Weber]

Comment on attachment 191620 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=191620&action=review

> Tools/DumpRenderTree/DumpRenderTree.gyp/DumpRenderTree.gyp:235
> +                'DumpRenderTree_resources',

What you can do to fix the problem I described in the other bug:

Add `'mac_bundle_resources': [ '<(PRODUCT_DIR)/DumpRenderTree.pak' ]` to this target, and remove process_outputs_as_mac_bundle_resources from your drt_resources target. (If this target here already has a mac_bundle_resources section, add the pak file to that.)

With that, everything should work.

>>> Tools/DumpRenderTree/DumpRenderTree.gyp/DumpRenderTree.gyp:-345
>>> -                    }],
>> 
>> I don't know why we were previously building the .pak file in <(INTERMEDIATE_DIR) and then copying it into <(PRODUCT_DIR). Is there a reason not to just build it into <(PRODUCT_DIR) by default?
> 
> Not sure, but it seems fine to write the final result to <(PRODUCT_DIR).

Maybe repack.py doesn't write the output file atomically?