Hi, ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it? Regards, Zoltan
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best. ----- ~Chris cmarrin@apple.com
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
On Sat, Aug 14, 2010 at 4:21 PM, <kb@inf.u-szeged.hu> wrote:
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
I'm surprised it isn't pulled as a .zip like the other third-party libraries (like icu, libxml, etc.) through the update-webkit script. -Darin
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
On Sat, Aug 14, 2010 at 4:21 PM, <kb@inf.u-szeged.hu> wrote:
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
I'm surprised it isn't pulled as a .zip like the other third-party libraries (like icu, libxml, etc.) through the update-webkit script.
Agreed. This is how I'd expect it to work. I don't understand why it's checked into WebKit. Now we're even building it as part of the build process, which I just don't understand. Are we having to alter the ANGLE source in the WebKit tree? That's the only reason I can think of why we would have a copy of the source checked in like this. dave (hyatt@apple.com)
On Aug 16, 2010, at 2:21 PM, David Hyatt wrote:
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
On Sat, Aug 14, 2010 at 4:21 PM, <kb@inf.u-szeged.hu> wrote:
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
I'm surprised it isn't pulled as a .zip like the other third-party libraries (like icu, libxml, etc.) through the update-webkit script.
Agreed. This is how I'd expect it to work. I don't understand why it's checked into WebKit. Now we're even building it as part of the build process, which I just don't understand. Are we having to alter the ANGLE source in the WebKit tree? That's the only reason I can think of why we would have a copy of the source checked in like this.
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 ----- ~Chris cmarrin@apple.com
On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin <cmarrin@apple.com> wrote:
On Aug 16, 2010, at 2:21 PM, David Hyatt wrote:
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:
On Sat, Aug 14, 2010 at 4:21 PM, <kb@inf.u-szeged.hu> wrote:
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the
root
WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google ( http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
I'm surprised it isn't pulled as a .zip like the other third-party libraries (like icu, libxml, etc.) through the update-webkit script.
Agreed. This is how I'd expect it to work. I don't understand why it's checked into WebKit. Now we're even building it as part of the build process, which I just don't understand. Are we having to alter the ANGLE source in the WebKit tree? That's the only reason I can think of why we would have a copy of the source checked in like this.
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. -Darin
On Aug 16, 2010, at 4:26 PM, Darin Fisher wrote:
On Mon, Aug 16, 2010 at 2:43 PM, Chris Marrin <cmarrin@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
On Mon, Aug 16, 2010 at 7:59 PM, Maciej Stachowiak <mjs@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@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. -Darin
On Sat, Aug 14, 2010 at 8:26 PM, Darin Fisher <darin@chromium.org> wrote:
On Sat, Aug 14, 2010 at 4:21 PM, <kb@inf.u-szeged.hu> wrote:
On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
Hi,
ANGLE looks like a graphics helper library. Why it is placed in the
root
WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it?
ANGLE is a library from Google (http://code.google.com/p/angleproject/) which is mirrored in the WebKit tree for convenience. Since it's not actually part of WebKit, it was felt that keeping it the root was best.
/3rdparty/ANGLE would be more straightforward in my opinion. Having this in the root is deceptive, personally I did not realized that it is a mirrored tree before your explantation.
I'm surprised it isn't pulled as a .zip like the other third-party libraries (like icu, libxml, etc.) through the update-webkit script.
-Darin
I realize now that I was only thinking about the WebKit windows port that relies on WebKitSupportLibrary.zip. I was wondering why ANGLE was not just included in there, but now I see that that zip isn't used on other platforms. -Darin
participants (6)
-
Chris Marrin
-
Darin Fisher
-
David Hyatt
-
kb＠inf.u-szeged.hu
-
Maciej Stachowiak
-
Zoltan Herczeg