Re: [webkit-dev] Renaming directories
On Dec 21, 2010, at 11:14 AM, Darin Adler wrote: Here’s my attempt to list the tests we currently have: - Automated regression tests (from LayoutTests directory). Many different types: Layout/pixel, text, script-tests, ref-tests coming soon, some requiring local server, some JavaScript only. Better organization needed. Need to replace old driver with new driver for non-Chromium platforms. Our #1 most critical tests. Includes copies of some entire test suites, such as ietestcenter and CSS 2.1 and sputnik. - Manual regression tests (in WebCore/manual-tests directory). These would be in the primary regression tests if we found a way to automate them. A good project for a contributor would be to convert these to automated tests one at a time to try to empty this directory. - Automated DOM binding generation regression tests (in WebCore/bindings/scripts/test). - JavaScript regression tests from Mozilla (in JavaScriptCore/tests/mozilla). We would like run-webkit-tests to know how to run these, but currently it does not. - SunSpider JavaScript performance test (in SunSpider). - SVG page load test performance test (in PageLoadTests/svg). I am not familiar with this one. - Platform-specific unit tests (in WebKit/chromium/tests, WebKit/gtk/tests, and WebKit/qt/tests). Not familiar with these, how they are run, or what their coverage are. - Python regression tests. Not sure where they are, but I see these failing on the bots so I know they exist. Maybe this list will give us some ideas about how we want to organize tests in the future. Plus in some shiny future: - automatable performance tests Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
Chromium already has a ton of architecture for automated runs of the PLT which I'm sure they'd be happy to share. (e.g. http://build.chromium.org/f/chromium/perf/dashboard/overview.html) The problem remains that (aside from the SVG PLT no one uses) we have no publicly available PLT content. :) -eric On Tue, Dec 21, 2010 at 1:23 PM, Simon Fraser simon.fra...@apple.com wrote: On Dec 21, 2010, at 11:14 AM, Darin Adler wrote: Here’s my attempt to list the tests we currently have: - Automated regression tests (from LayoutTests directory). Many different types: Layout/pixel, text, script-tests, ref-tests coming soon, some requiring local server, some JavaScript only. Better organization needed. Need to replace old driver with new driver for non-Chromium platforms. Our #1 most critical tests. Includes copies of some entire test suites, such as ietestcenter and CSS 2.1 and sputnik. - Manual regression tests (in WebCore/manual-tests directory). These would be in the primary regression tests if we found a way to automate them. A good project for a contributor would be to convert these to automated tests one at a time to try to empty this directory. - Automated DOM binding generation regression tests (in WebCore/bindings/scripts/test). - JavaScript regression tests from Mozilla (in JavaScriptCore/tests/mozilla). We would like run-webkit-tests to know how to run these, but currently it does not. - SunSpider JavaScript performance test (in SunSpider). - SVG page load test performance test (in PageLoadTests/svg). I am not familiar with this one. - Platform-specific unit tests (in WebKit/chromium/tests, WebKit/gtk/tests, and WebKit/qt/tests). Not familiar with these, how they are run, or what their coverage are. - Python regression tests. Not sure where they are, but I see these failing on the bots so I know they exist. Maybe this list will give us some ideas about how we want to organize tests in the future. Plus in some shiny future: - automatable performance tests Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Platform specific fields on WebCore::HistoryItem
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem. ***
Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
OwnPtrHashMapString, RetainPtrid m_transientProperties;
#endif
#if PLATFORM(QT)
QVariant m_userData;
#endif
#if PLATFORM(ANDROID)
RefPtrAndroidWebHistoryBridge m_bridge;
#endif
};
I'm not sure how these fields are used, and I would greatly appreciate input
from the respective
port maintainers.
Thanks,
-Darin
[1]
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/loader/HistoryController.cppq=updateForReloadexact_package=chromiumsa=Ncd=1ct=rc
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem. ***
Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not change while
the page is cached!
OwnPtrHashMapString, RetainPtrid m_transientProperties;
This is to support arbitrary WebKit Mac API and has nothing to do with the URL
identity of the item.
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem.
*** Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not change
while the page is cached!
OK, I will assert that it is 0.
OwnPtrHashMapString, RetainPtrid m_transientProperties;
This is to support arbitrary WebKit Mac API and has nothing to do with the
URL identity of the item.
OK, thanks!
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitTools has changed to Tools
Thanks for the rename! I love the fact I can access Tools in just 2 key strokes (T + tab). - Ryosuke On Fri, Dec 17, 2010 at 4:09 PM, Dan Bernstein m...@apple.com wrote: Done in r74301. On Nov 20, 2010, at 11:29 PM, Dan Bernstein wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of ext Darin Fisher
Sent: Tuesday, December 21, 2010 2:39 PM
To: WebKit Development
Subject: [webkit-dev] Platform specific fields on WebCore::HistoryItem
I'm working on fixing some session history bugs related to a HistoryItem's URL
property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem. *** Do
any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(QT)
QVariant m_userData;
#endif
This is arbitrary data that embeders of QtWebkit can store. It should not
interfere with the changes you are making.
Yael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Dec 18, 2010, at 2:23 AM, Adam Barth wrote: While we're in the mood to rename directories, would these renamings make sense: WebKitSite = WebSite Just Site might be more Tab-complete-friendly, though it is less precise. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Dec 21, 2010, at 11:14 AM, Darin Adler wrote: Here’s my attempt to list the tests we currently have: - Automated regression tests (from LayoutTests directory). Many different types: Layout/pixel, text, script-tests, ref-tests coming soon, some requiring local server, some JavaScript only. Better organization needed. Need to replace old driver with new driver for non-Chromium platforms. Our #1 most critical tests. Includes copies of some entire test suites, such as ietestcenter and CSS 2.1 and sputnik. - Manual regression tests (in WebCore/manual-tests directory). These would be in the primary regression tests if we found a way to automate them. A good project for a contributor would be to convert these to automated tests one at a time to try to empty this directory. - Automated DOM binding generation regression tests (in WebCore/bindings/scripts/test). - JavaScript regression tests from Mozilla (in JavaScriptCore/tests/mozilla). We would like run-webkit-tests to know how to run these, but currently it does not. - SunSpider JavaScript performance test (in SunSpider). - SVG page load test performance test (in PageLoadTests/svg). I am not familiar with this one. - Platform-specific unit tests (in WebKit/chromium/tests, WebKit/gtk/tests, and WebKit/qt/tests). Not familiar with these, how they are run, or what their coverage are. - Python regression tests. Not sure where they are, but I see these failing on the bots so I know they exist. Maybe this list will give us some ideas about how we want to organize tests in the future. We also have WebKit2 API tests (or soon will if they aren't landed yet). And we have JavaScriptCore API tests which are not run automated. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem.
*** Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not change
while the page is cached!
OK, I will assert that it is 0.
Awesome, I found a layout test where the URL of the HistoryItem changes, and
there is an associated cached page for the HistoryItem! I presume the right
fix is to clear the cached page.
In case you are interested, the layout test where this happens is:
fast/history/timed-refresh-in-cached-frame.html
-Darin
OwnPtrHashMapString, RetainPtrid m_transientProperties;
This is to support arbitrary WebKit Mac API and has nothing to do with the
URL identity of the item.
OK, thanks!
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Dec 21, 2010, at 1:49 PM, Maciej Stachowiak wrote: And we have JavaScriptCore API tests which are not run automated. The JSC API tests run as part of run-javascript-tests, which the build bots do execute --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
We also have WebKit2 API tests (or soon will if they aren't landed yet). The WebKit2 tests have been in the tree (under Tools/TestWebKitAPI) for bit now. The harness can also be used to test WTF data structures and has a sample test of basic testing of Vector. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a
HistoryItem's URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem.
*** Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not change
while the page is cached!
OK, I will assert that it is 0.
Awesome, I found a layout test where the URL of the HistoryItem changes,
and there is an associated cached page for the HistoryItem! I presume the
right fix is to clear the cached page.
No no no!!!
Why is anyone trying to do anything to the URL of an item that represents a
cached page???
Hmm, the testcase is simply assigning location within onload (the equivalent
of location.replace). The document is getting replaced with a new document,
but the same HistoryItem is being overwritten with the URL of the new
document.
I'm not super familiar with the cached page implementation since Chromium
does not enable it, but if that system assumes there is a 1:1 relationship
between HistoryItems and cached pages / documents, then that could be
problematic.
I'm toying with calling HistoryController::invalidateCurrentItemCachedPage()
in this case, but maybe that would be suboptimal?
In case you are interested, the layout test where this happens is:
fast/history/timed-refresh-in-cached-frame.html
Shouldn't the timed refresh be paused while the page is cached, and only
resume once the page is brought out?
The issue comes up well before the meta refresh timer expires. I could
remove that bit of the testcase, and the issue would remain. This is all
about issuing a client redirect on a page that has been cached.
-Darin
In other words, should the URL only be changed after the page is restored?
~Brady
-Darin
OwnPtrHashMapString, RetainPtrid m_transientProperties;
This is to support arbitrary WebKit Mac API and has nothing to do with
the URL identity of the item.
OK, thanks!
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Tue, Dec 21, 2010 at 3:59 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.orgwrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.comwrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a
HistoryItem's URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem.
*** Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not
change while the page is cached!
OK, I will assert that it is 0.
Awesome, I found a layout test where the URL of the HistoryItem changes,
and there is an associated cached page for the HistoryItem! I presume the
right fix is to clear the cached page.
No no no!!!
Why is anyone trying to do anything to the URL of an item that represents
a cached page???
Hmm, the testcase is simply assigning location within onload (the
equivalent of location.replace). The document is getting replaced with a
new document, but the same HistoryItem is being overwritten with the URL of
the new document.
I'm not super familiar with the cached page implementation since Chromium
does not enable it, but if that system assumes there is a 1:1 relationship
between HistoryItems and cached pages / documents, then that could be
problematic.
I'm toying with
calling HistoryController::invalidateCurrentItemCachedPage() in this case,
but maybe that would be suboptimal?
OK, false alarm. The issue is as follows:
The cached page corresponding to the new document is assigned to the
HistoryItem before we change its URL. In other words, I don't need to do
anything special.
-Darin
In case you are interested, the layout test where this happens is:
fast/history/timed-refresh-in-cached-frame.html
Shouldn't the timed refresh be paused while the page is cached, and only
resume once the page is brought out?
The issue comes up well before the meta refresh timer expires. I could
remove that bit of the testcase, and the issue would remain. This is all
about issuing a client redirect on a page that has been cached.
-Darin
In other words, should the URL only be changed after the page is restored?
~Brady
-Darin
OwnPtrHashMapString, RetainPtrid m_transientProperties;
This is to support arbitrary WebKit Mac API and has nothing to do with
the URL identity of the item.
OK, thanks!
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform specific fields on WebCore::HistoryItem
On Dec 21, 2010, at 4:26 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 3:59 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 2:56 PM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 1:57 PM, Darin Fisher wrote:
On Tue, Dec 21, 2010 at 11:49 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 21, 2010 at 11:46 AM, Brady Eidson beid...@apple.com wrote:
On Dec 21, 2010, at 11:39 AM, Darin Fisher wrote:
I'm working on fixing some session history bugs related to a HistoryItem's
URL property changing.
See for example the call to HistoryItem::setURL in
HistoryController::updateForReload [1].
I'm curious about the platform specific fields on WebCore::HistoryItem.
*** Do any of those need to
be updated when the URL of the HistoryItem changes? ***
Here are the fields I'm referring to:
class HistoryItem ... {
private:
...
#if PLATFORM(MAC)
RetainPtrid m_viewState;
This is used for the Page Cache only. The URL had sure better not change
while the page is cached!
OK, I will assert that it is 0.
Awesome, I found a layout test where the URL of the HistoryItem changes, and
there is an associated cached page for the HistoryItem! I presume the right
fix is to clear the cached page.
No no no!!!
Why is anyone trying to do anything to the URL of an item that represents a
cached page???
Hmm, the testcase is simply assigning location within onload (the equivalent
of location.replace). The document is getting replaced with a new document,
but the same HistoryItem is being overwritten with the URL of the new
document.
I'm not super familiar with the cached page implementation since Chromium
does not enable it, but if that system assumes there is a 1:1 relationship
between HistoryItems and cached pages / documents, then that could be
problematic.
I'm toying with calling HistoryController::invalidateCurrentItemCachedPage()
in this case, but maybe that would be suboptimal?
OK, false alarm. The issue is as follows:
The cached page corresponding to the new document is assigned to the
HistoryItem before we change its URL. In other words, I don't need to do
anything special.
Sounds fine.
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Mon, Dec 20, 2010 at 11:22 PM, Adam Barth aba...@webkit.org wrote: Do we want to move LayoutTests = RegressionTests? My sense is that would be more disruptive than the other moves. Last time we discussed this question, Darin encouraged us to view the future as larger than the past and to consider the long term value in these changes, which would point to moving the directory. Why don't we do this as we change the format of render tree dumps. We can remove expected tests from LayoutTests, move tests to RegressionTests with new expected results. We can even incrementally migrate if we taught DRT to output two different results depending on which directory we're in. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we do this as we change the format of render tree dumps. We can remove expected tests from LayoutTests, move tests to RegressionTests with new expected results. I don't think an incremental migration will work well here, especially if it can't be easily automated (if it involves output format changes). We're going to have both directories for years, and people new to the project will be confused as to which tests to run, where to add new ones (if related ones haven't been migrated yet), etc. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Tue, Dec 21, 2010 at 6:16 PM, Mihai Parparita mih...@chromium.orgwrote: On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we do this as we change the format of render tree dumps. We can remove expected tests from LayoutTests, move tests to RegressionTests with new expected results. I don't think an incremental migration will work well here, especially if it can't be easily automated (if it involves output format changes). We can stop generating results in LayoutTests, no? We're going to have both directories for years, and people new to the project will be confused as to which tests to run, where to add new ones (if related ones haven't been migrated yet), etc. I'm not suggesting that we do this over time. I think we should still have a dedicated time period to convert all tests. But even if we were doing this in a short period of time (say in 24 hours), it'll be nice if we could keep the bots green. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Page Cache for web-pages with plugin
On Tue, Dec 21, 2010 at 12:56 AM, Sam Weinig sam.wei...@gmail.com wrote: No one (that I know of) is currently working on making plugins work with the PageCache. The most pressing road block to make it work is infrastructure to kill and restart plugins (or alternatively, and reliable way to pause them, perhaps using their current out of process nature, or perhaps proposing API on plugin-futures for it). -Sam Thanks for the update Sam ! Also, I was wondering if it is possible to save the page-cache to non-volatile disk (e.g. at the end of session) and later 'restore' it when starting a new session - this hot cache might be useful if e.g. the user usually browses the same set of sites. Any idea if any one has worked on it or if it is even possible from an implementation point of view ? regards, Aneesh On Mon, Dec 20, 2010 at 1:29 AM, Aneesh Bhasin contact.ane...@gmail.com wrote: Hi All, I will really appreciate if someone could help me with this.. regards, Aneesh On Fri, Dec 17, 2010 at 11:17 AM, Aneesh Bhasin contact.ane...@gmail.com wrote: Hi All, I was wondering as to what is the current status for maintaining a page cache for webpages which contain some plugin ( https://bugs.webkit.org/show_bug.cgi?id=13634) ? The last update on that bug report said that work is ongoing towards it. If someone could point me to the right direction here that it will be very helpful.. Thanks and regards, Aneesh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
On Tue, Dec 21, 2010 at 11:30 PM, Darin Adler da...@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. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
