[webkit-dev] ANGLE

Darin Fisher darin at chromium.org
Tue Aug 17 10:45:06 PDT 2010

On Mon, Aug 16, 2010 at 7:59 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> On Aug 16, 2010, at 4:26 PM, Darin Fisher wrote:
> On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin <cmarrin at apple.com> wrote:
>> I'm not familiar with what update-webkit does. But the only reason ANGLE
>> is in the root is because a couple of people here said that was the best way
>> to do it. ANGLE is a pretty new project and it doesn't look to me like they
>> are producing .zip files yet. I'd hate to use TOT because that could
>> introduce instability at random times. We were originally going to just put
>> a .a in the tree but someone (maybe Maciej?) thought that was a bad idea.
>> There are many things we can do:
>> 1) Leave it as is
>> 2) Move the source to a better subdir
>> 3) Check angle.a into WebKit and get rid of the source
>> 4) Checkout ANGLE from its source repo and build it
>> I don't have any preference, except that if we choose option 4 we make
>> sure to get a known rev to avoid instability
> #4 is what Chromium does for numerous dependencies (including WebKit).
> It seems like it would be fairly easy to extend update-webkit to checkout
> ANGLE at the right revision for ports that require it.
> For purposes of Apple internal process, if we eventually want to ship a
> version of WebKit that relies on ANGLE, we need to submit it as source, from
> an Apple-managed repository (both for purposes of continuity and so we can
> add our own branches and tags etc). This is done for a number of open source
> projects that are developed completely external to Apple and minimally
> modified, if at all.
> We could, if we wanted to, have a completely separate copy of ANGLE source
> that's checked into a separate Apple-internal repository, and provide a
> version of ANGLE for use when building WebKit in some completely different
> way, such as by checking in a binary, or by pulling from the upstream
> repository live. However, this would create busywork to keep multiple
> version in sync, and a risk of version skew if our internal copy ever gets
> out of sync with whatever the webkit.org tree uses.
> Granted, this mostly affects Apple (and potentially users of software we
> ship, if we accidentally ship a different version than what was tested). I'm
> willing to consider that we should change our approach if it would create a
> greater benefit for other WebKit contributors. But before we do that, I'd
> like to understand the tangible benefits to others, if any.
> (Note, this only applies to #3 and #4 above; there's no material difference
> between #1 and #2 for us.)
> Regards,
> Maciej
Thanks for the details.  I'm not sure that it matters enough.  I just note
that for Chromium, we end up with two copies of ANGLE because of this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100817/48954130/attachment.html>

More information about the webkit-dev mailing list