| Summary: | build a DumpRenderTree.pak even on windows | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dirk Pranke <dpranke> | ||||
| Component: | New Bugs | Assignee: | Dirk Pranke <dpranke> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | jamesr, jochen, thakis, tony | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 111508 | ||||||
| Attachments: |
|
||||||
|
Description
Dirk Pranke
2013-03-05 17:44:43 PST
Created attachment 191620 [details]
Patch
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? 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). Comment on attachment 191620 [details] Patch Clearing flags on attachment: 191620 Committed r144863: <http://trac.webkit.org/changeset/144863> All reviewed patches have been landed. Closing bug. 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. 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. Er, that's bug 111509, not bug 111506. (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. 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? |