[webkit-dev] Renaming directories

[Mark Rowe]

On 2010-12-22, at 09:37, Kenneth Russell wrote:

> On Tue, Dec 21, 2010 at 11:40 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Tue, Dec 21, 2010 at 11:30 PM, Darin Adler <darin at apple.com> wrote:
>>> On Dec 21, 2010, at 11:20 PM, Adam Barth wrote:
>>>> Looking through my working copy, there are a couple of things that aren't obvious to me where they would go in this structure: WebKitBuild and WebKitLibraries. Maybe these would become Build and Libraries as top-level directories?
>>> 
>>> WebKitBuild is a builds and intermediates directory for Xcode, specific to Mac. It’s set up by the WebKit project build scripts for people who don’t have Xcode set to use a particular build directory, because the WebKit projects need to build into a single build directory. I don’t have one of those on my computer because I do have WebKit set to use a single builds and intermediates directory (in my case ~/Build). I don’t know the right answer for what to do about this. We just need a sensible default for people building on Mac. Maybe calling it just Build and leaving it at the top level would be fine.
>>> 
>>> WebKitLibraries contains libraries and header files needed to build WebKit on Mac and Windows. The name Libraries would be OK for those things; I’m not sure it’s optimal.
>> 
>> What about ANGLE?  My understanding is that ANGLE is third-party code
>> that we have checked into the tree but that we're not supposed to
>> modify.  Should that go in Sources or in Libraries?  In Chrome,
>> similar things are placed in a ThirdParty directory to remind folks
>> not to modify them.
> 
> Since ANGLE was first checked in to WebKit, a WebCore/thirdparty
> directory was added. It would make most sense to move ANGLE into it.

The fact that code is in the WebKit SVN repository at all seems questionable to me.  It's not under either of the accepted licenses for code in the WebKit tree.

- Mark

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