[webkit-dev] ANGLE

[Maciej Stachowiak]

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






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