Bug 87045 - [chromium] Build content_shell from within WebKit
: [chromium] Build content_shell from within WebKit
Status: RESOLVED WONTFIX
Product: WebKit
Classification: Unclassified
Component: New Bugs
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: jochen
:
Depends on: 91308
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 14:31 PDT by jochen
Modified: 2013-04-08 14:56 PDT (History)
9 users (show)

See Also:


Attachments
Patch (3.54 KB, patch)
2012-05-21 14:31 PDT, jochen
no flags Details | Formatted Diff | Diff
Patch (3.59 KB, patch)
2012-07-23 03:53 PDT, jochen
no flags Details | Formatted Diff | Diff
Changes for Android (2.12 KB, text/plain)
2012-07-24 07:12 PDT, Peter Beverloo
no flags Details
Adding Mac DEPS. (4.11 KB, patch)
2012-10-30 09:17 PDT, Mike West
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jochen 2012-05-21 14:31:11 PDT
[chromium] Build content_shell from within WebKit
Comment 1 jochen 2012-05-21 14:31:44 PDT
Created attachment 143098 [details]
Patch
Comment 2 jochen 2012-05-21 14:36:56 PDT
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
Comment 3 Levi Weintraub 2012-05-21 14:38:35 PDT
(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?
Comment 4 Levi Weintraub 2012-05-21 14:38:53 PDT
(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)
Comment 5 jochen 2012-05-21 14:41:05 PDT
(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!
Comment 6 Levi Weintraub 2012-05-21 14:45:03 PDT
(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.
Comment 7 jochen 2012-05-21 15:05:25 PDT
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 8 WebKit Review Bot 2012-05-21 15:24:46 PDT
Comment on attachment 143098 [details]
Patch

Attachment 143098 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12740556
Comment 9 Darin Fisher (:fishd, Google) 2012-06-10 22:50:29 PDT
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.
Comment 10 jochen 2012-06-10 23:31:10 PDT
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 11 Dirk Pranke 2012-06-13 12:50:16 PDT
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 ...
Comment 12 Darin Fisher (:fishd, Google) 2012-07-08 07:17:04 PDT
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.
Comment 13 jochen 2012-07-23 03:53:25 PDT
Created attachment 153768 [details]
Patch
Comment 14 Peter Beverloo 2012-07-24 07:12:50 PDT
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.
Comment 15 jochen 2012-07-24 07:20:45 PDT
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
Comment 16 Mike West 2012-10-30 09:17:02 PDT
Created attachment 171464 [details]
Adding Mac DEPS.