Summary: | [chromium] Build content_shell from within WebKit | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | jochen | ||||||||||
Component: | New Bugs | Assignee: | jochen | ||||||||||
Status: | RESOLVED WONTFIX | ||||||||||||
Severity: | Normal | CC: | dglazkov, dpranke, eae, fishd, jam, leviw, peter, schenney, webkit.review.bot | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Bug Depends on: | 91308 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
jochen
2012-05-21 14:31:11 PDT
Created attachment 143098 [details]
Patch
this is WIP patch for people that want to experiment with this. I tested this on Linux only The required chromium side is here: https://chromiumcodereview.appspot.com/10388218 (In reply to comment #2) > The required chromium side is here: https://chromiumcodereview.appspot.com/10388218 Is there anything stopping us from putting in the Chromium side? It doesn't actually change anything, no? (In reply to comment #3) > Is there anything stopping us from putting in the Chromium side? It doesn't actually change anything, no? (I mean in the standard build case) (In reply to comment #4) > (In reply to comment #3) > > Is there anything stopping us from putting in the Chromium side? It doesn't actually change anything, no? > > (I mean in the standard build case) I just uploaded the CL, gimme a sec! (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Is there anything stopping us from putting in the Chromium side? It doesn't actually change anything, no? > > > > (I mean in the standard build case) > > I just uploaded the CL, gimme a sec! Sorry, I wasn't trying to pressure you, just validating my understanding of that patch. here's the steps to build content_shell right now: 1) update-webkit --chromium 2) webkit-patch apply-attachment --no-clean --no-update 143098 3) cd Source/WebKit/chromium; gclient sync 4) curl -o - https://chromiumcodereview.appspot.com/download/issue10388218_4002.diff | patch -p1 5) python ./gyp_webkit 6) webkit-build --chromium --debug this should give you out/Debug/content_shell run with --dump-render-tree for a DRT like interface, or with --remote-debugging-port=9222 for devtools once the chromium side has landed, steps 4 and 5 are not required Comment on attachment 143098 [details] Patch Attachment 143098 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12740556 Comment on attachment 143098 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=143098&action=review > Source/WebKit/chromium/DEPS:142 > + 'third_party/flac': don't you think this file is getting out of control? the webkit repository shouldn't encode all of these details about what packages are required to build chromium. somehow we should extract that information from a file maintained in the chromium repository. webkit repository should just indicate the version of chromium and the location of the repository. problem: if the set of things chromium depends on changes, then you have to modify this file. the file listing the things chromium depends on should live in the chromium repository so that when those changes are made, they can be made as part of the same CL. It is already out of control... I think the right solution is that the.individual modules in chromium like webkit support or content should specify their own DEPS files instead of having this huge single DEPS in src/ Comment on attachment 143098 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=143098&action=review >> Source/WebKit/chromium/DEPS:142 >> + 'third_party/flac': > > don't you think this file is getting out of control? the webkit repository > shouldn't encode all of these details about what packages are required to > build chromium. somehow we should extract that information from a file > maintained in the chromium repository. webkit repository should just > indicate the version of chromium and the location of the repository. > > problem: if the set of things chromium depends on changes, then you have > to modify this file. the file listing the things chromium depends on > should live in the chromium repository so that when those changes are > made, they can be made as part of the same CL. as an alternative to multiple DEPS files in chrome, maybe we need to add some sort of wildcard or dependency or cascade feature into gclient, so you we could say something like 'content_deps': and have that get expanded to some list on the chromium-side ... Yes, defining a variable like 'content_deps' on the chromium side that WebKit could use seems good. Jochen, the multiple DEPS file things suffers from diamond dependency problems. What happens if two modules don't agree on the version of 'net' or 'base' that they require? A single master list is simpler. Created attachment 153768 [details]
Patch
Created attachment 154053 [details]
Changes for Android
Hi Jochen, I've attached the changes (to your patch) required to make this work for Android.
At this moment we're not yet able to build content_shell itself. Instead, the content_shell_apk target will be sufficient for now, which right now wraps the Java files and creates an .apk. As work continues in bringing content_shell up on the Chromium side, dependencies will be added to the content_shell_apk target (i.e. one on content_shell itself).
Concretely, this means that it won't work at all for Android :-). As development still is actively ongoing, I think it's best *not* to add a dependency on either content_shell or content_shell_apk for now when building for Android, mostly to avoid random build breakages after Chromium DEPS rolls. Once the work stabilizes and is closer to being finished, we can enable the dependency and make steps towards switching over. Adding the missing dependencies now should be fine, however.
Thank you for the feedback. Right now, this bug is just for people that want to experiment with content shell in WebKit. I don't think it'll ever land, as webkit should not depend on content The plan is (roughly) to add methods to webkit_support for creating a webview that will either be created using TestShell or ContentShell Created attachment 171464 [details]
Adding Mac DEPS.
|