Re: [chromium-dev] Heads up: safely ignored regression on Linux Startup perf test
This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. -Darin On Tue, Nov 17, 2009 at 8:52 PM, John Abd-El-Malek j...@chromium.org wrote: Heads up to explain the sudden jump on Linux Startup perf test. I just submitted r32264 which makes opening and closing processes happen off the UI thread. Surprisingly enough, according to UMA stats these would take an average of 1s on Linux for the first renderer, and 100ms on Windows. Subsequent launches were very quick on Linux, but on Windows averaged 50ms. When using session restore with many tabs, this would block the UI thread for quite a bit. Also, Linux had code which might sleep for up to 2s on the UI thread waiting for the process to die. Linux Warm Startuphttp://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warmperf test is showing a big regression (200ms-300ms). With Elliott's insight, I tracked this down to the fact that the UI thread is very busy at startup handling GTK messages, so the posted task back to it to tell BrowserRenderProcessHost that the handle is available is queued up. This parallelization is exactly what we want though, and the Linux New Tab Coldhttp://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150test went from ~615ms to ~440ms. It's hard to see a change on Linux Warm Startuphttp://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=cold because of all the noise. As for other platforms: Mac Startuphttp://build.chromium.org/buildbot/perf/mac-release-10.5/startup/report.html?history=150graph=warm (both warm and cold) went from around 307ms to 290ms, while Mac New Tab Cold http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 went from 720ms to 620ms. Windows didn't have much change. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] new matrix-view perf dashboard
On Tue, Nov 17, 2009 at 9:07 PM, Steven Knight s...@chromium.org wrote: 1) I cannot see Dromaeo benchmark; Added. Thanks a lot. If I am not asking for too much, could you move Dromaeo one row up, to make a group of SunSpider/V8/DOM/Dromaeo (not to be split by morejs)? 2) is it possible to make column titles sticky? I mean that when you scroll down and don't see nor footer, nor header, it's hard to tell the flavour of each graph in the raw. I'm sure there's a way, but that's beyond my JS skills. As a stopgap until something more sophisticated comes along, I added a quick hack to replicate the column title row every four graphs, so you should probably have the build slave title in view (or very close) on most displays. Yep, that works for me. Still, what is the file in repo to change if I, say, would have some spare cycles to add sticky column names? yours, anton. And just an observation. At least for me newer page loads notably faster than the previous one. yours, anton. On Tue, Nov 17, 2009 at 3:05 AM, Steven Knight s...@chromium.org wrote: The current perf dashboard is getting long and unwieldy. I've put up a new page which packs the same thumbnail graphs into a matrix: http://build.chromium.org/buildbot/perf/dashboard/perf.html Rows are the various perf tests we run, columns are the different build slaves. It compresses the graphs horizontally to fit your window size at page load time. (No dynamic resizing.) Row (test) and column (slave) headings are links that take you to separate pages that show just one test's graphs from all slaves (row), or just all the test graphs for a single slave (column). In addition to making it more convenient to focus on a specific test's/slave's results, these individual pages also have the advantage of (re)loading a lot more quickly than the full dashboard, since you're only pulling down and displaying data for about ten graphs, instead of the ~100 thumbnail graphs in the full dashboard. The pages for the new matrix Perf view and the old classic Perf view now have clickable links at the top for switching between the two. (Neither is very fast, though, given that you load ~100 graphs each time you switch). Let me know if you notice any problems or have any suggestions for making this more useful. --SK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Linux: gold linker users should upgrade to 2.20 soon.
On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang thes...@chromium.org wrote: If you installed gold through [1], please run it again. I've updated the script at r32315 to install gold 2.20. I've also updated all the Linux build / try bots to gold 2.20. [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh Rather, use the version from r32317 so you don't lose your original ld. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Mac10.5 Tests (dbg)(2), revision 32319
Automatically closing tree for unit_tests on Mac10.5 Tests (dbg)(2) http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests%20%28dbg%29%282%29/builds/8744 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests%20%28dbg%29%282%29 --= Automatically closing tree for unit_tests on Mac10.5 Tests (dbg)(2) =-- Revision: 32319 Blame list: jor...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] new matrix-view perf dashboard
Thanks a lot. If I am not asking for too much, could you move Dromaeo one row up, to make a group of SunSpider/V8/DOM/Dromaeo (not to be split by morejs)? Done. If you regularly want to restrict your view to just those rows, you can bookmark a URL with a constructed test= parameter: http://chrome-web.corp/buildbot/perf/dashboard/perf.html?test=sunspider,v8_benchmark,dom_perf,dromaeo Loads less than 1/3 of the full table, so much faster... Still, what is the file in repo to change if I, say, would have some spare cycles to add sticky column names? That would be really welcome. Here's the svn: path: svn://chrome-svn/chrome/trunk/tools/buildbot/perf/dashboard/perf.html Thanks, --SK yours, anton. And just an observation. At least for me newer page loads notably faster than the previous one. yours, anton. On Tue, Nov 17, 2009 at 3:05 AM, Steven Knight s...@chromium.org wrote: The current perf dashboard is getting long and unwieldy. I've put up a new page which packs the same thumbnail graphs into a matrix: http://build.chromium.org/buildbot/perf/dashboard/perf.html Rows are the various perf tests we run, columns are the different build slaves. It compresses the graphs horizontally to fit your window size at page load time. (No dynamic resizing.) Row (test) and column (slave) headings are links that take you to separate pages that show just one test's graphs from all slaves (row), or just all the test graphs for a single slave (column). In addition to making it more convenient to focus on a specific test's/slave's results, these individual pages also have the advantage of (re)loading a lot more quickly than the full dashboard, since you're only pulling down and displaying data for about ten graphs, instead of the ~100 thumbnail graphs in the full dashboard. The pages for the new matrix Perf view and the old classic Perf view now have clickable links at the top for switching between the two. (Neither is very fast, though, given that you load ~100 graphs each time you switch). Let me know if you notice any problems or have any suggestions for making this more useful. --SK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Heads up: safely ignored regression on Linux Startup perf test
Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.com wrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 32350
Automatically closing tree for compile on Chromium XP http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/8751 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP --= Automatically closing tree for compile on Chromium XP =-- Revision: 32334, 32335, 32336, 32337, 32339, 32340, 32341, 32342, 32344, 32345, 32346, 32348, 32350 Blame list: c...@chromium.org,dmacl...@chromium.org,e...@chromium.org,i...@chromium.org,jap...@chromium.org,jcam...@chromium.org,je...@chromium.org,j...@chromium.org,kka...@chromium.org,mrosse...@chromium.org,rse...@chromium.org,viettrung...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] new matrix-view perf dashboard
On Wed, Nov 18, 2009 at 8:15 PM, Steven Knight s...@chromium.org wrote: Thanks a lot. If I am not asking for too much, could you move Dromaeo one row up, to make a group of SunSpider/V8/DOM/Dromaeo (not to be split by morejs)? Done. Thank you very much. If you regularly want to restrict your view to just those rows, you can bookmark a URL with a constructed test= parameter: http://chrome-web.corp/buildbot/perf/dashboard/perf.html?test=sunspider,v8_benchmark,dom_perf,dromaeo Loads less than 1/3 of the full table, so much faster... Very cool, thanks again. Still, what is the file in repo to change if I, say, would have some spare cycles to add sticky column names? That would be really welcome. Here's the svn: path: svn://chrome-svn/chrome/trunk/tools/buildbot/perf/dashboard/perf.html And the last thanks, Steven. yours, anton. And just an observation. At least for me newer page loads notably faster than the previous one. yours, anton. On Tue, Nov 17, 2009 at 3:05 AM, Steven Knight s...@chromium.org wrote: The current perf dashboard is getting long and unwieldy. I've put up a new page which packs the same thumbnail graphs into a matrix: http://build.chromium.org/buildbot/perf/dashboard/perf.html Rows are the various perf tests we run, columns are the different build slaves. It compresses the graphs horizontally to fit your window size at page load time. (No dynamic resizing.) Row (test) and column (slave) headings are links that take you to separate pages that show just one test's graphs from all slaves (row), or just all the test graphs for a single slave (column). In addition to making it more convenient to focus on a specific test's/slave's results, these individual pages also have the advantage of (re)loading a lot more quickly than the full dashboard, since you're only pulling down and displaying data for about ten graphs, instead of the ~100 thumbnail graphs in the full dashboard. The pages for the new matrix Perf view and the old classic Perf view now have clickable links at the top for switching between the two. (Neither is very fast, though, given that you load ~100 graphs each time you switch). Let me know if you notice any problems or have any suggestions for making this more useful. --SK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Linux: gold linker users should upgrade to 2.20 soon.
On Wed, Nov 18, 2009 at 3:00 AM, Lei Zhang thes...@chromium.org wrote: On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang thes...@chromium.org wrote: If you installed gold through [1], please run it again. I've updated the script at r32315 to install gold 2.20. I've also updated all the Linux build / try bots to gold 2.20. [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh Rather, use the version from r32317 so you don't lose your original ld. Whoops, the script outsmarted me and does not install gold if it's already installed. If you need to upgrade, you have to uninstall first. To quote the script: cd /usr/bin; sudo rm ld; sudo mv ld.orig ld -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] FYI ... you might find some issues missing in issue_tracker
Hi all, Just a heads' up ... we've discovered a bug in Issue Tracker that has caused a few of our issues (along with a issues from other projects) to be partially deleted from the database. The team is aware of the problem and working on a solution, but it may not be fully patched until after Thanksgiving because they're in the midst of a release. So far I've only found two issues missing, so you probably won't notice this unless you're exceptionally anal, like I am :) -- Dirk -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 32383
Automatically closing tree for compile on Chromium XP http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/8754 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP --= Automatically closing tree for compile on Chromium XP =-- Revision: 32363, 32364, 32365, 32366, 32368, 32369, 32370, 32371, 32372, 32373, 32374, 32375, 32376, 32378, 32381, 32382, 32383 Blame list: dmacl...@chromium.org,dpra...@google.com,grego...@google.com,k...@chromium.org,m...@chromium.org,mpcompl...@chromium.org,osh...@chromium.org,pkast...@chromium.org,thes...@chromium.org,w...@chromium.org,z...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Memory purger available for testing
This morning I checked in the central bits of the MemoryPurger. This allows you to start Chrome with --purge-memory-button, which will add a button to the Task Manager called Purge Memory. Pressing this button will attempt to free as much memory as possible* from the browser and renderer processes. My hope is that this will be useful in finding cases where we're using too much memory; I'd like to eventually hook pieces of this to automatic signals. Please let me know anything interesting you find with this. PK *Currently purged: Browser process: History backend, Web data backend (search keywords etc.), Proxy resolver JS heaps, Safe Browsing backend, TCMalloc free pages Renderer process: Spellchecker, WebCore object cache, WebCore font cache, WebCore cross-origin preflight cache, sqlite database backing stores, JS heap, TCMalloc free pages. Let me know if there are major memory consumers I'm missing. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: New Presubmit actions
First, I'd prefer to keep the presubmit checks from having any side-effect. For a) You haven't mentioned which editor you use but if it is a problem for you, maybe you should tweak the editor? VS, emacs, vim can be modified to do it or at least highlight it; I don't know about xcode. Otherwise a very simple python script can do it for you, maybe you could create a new kind of gcl hook. git already has functionality for commit hooks. For b), follow the steps at http://dev.chromium.org/developers/coding-style#TOC-Subversion-properties It's necessary for git usage too. M-A On Wed, Nov 18, 2009 at 4:26 PM, Dave MacLachlan dmacl...@google.com wrote: Hey Marc-Antoine: What would it take to have the presubmit scripts automagically do the following: a) Remove all whitespace at the end of .h, .c, .cc and .mm files? b) Apply 'svn pset svn:eol-style LF' as necessary to .h, .c, .cc and .mm files? This would save me a great deal of time. My editor of choice does not take care of getting rid of the whitespace for me. Cheers, Dave -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Memory purger available for testing
On Wed, Nov 18, 2009 at 1:16 PM, Peter Kasting pkast...@google.com wrote: *Currently purged: Browser process: History backend, Web data backend (search keywords etc.), Proxy resolver JS heaps, Safe Browsing backend, TCMalloc free pages Chase noted I forgot to list one other thing I'm purging in the browser process: Backing stores. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: New Presubmit actions
I use a script like the following to fix trailing whitespace when I
get errors (I pipe the output of gcl presubmit to it). You can easily
extend it to fix bad line-endings (it will already ensure all touched
files use \n) and it should be straightforward to extend it to do the
propset stuff as well.
Cheers,
Jói
import re
import sys
output = sys.stdin.read()
filenames = []
# First find trailing whitespace concerns as per Chrome's presubmit.
rex = re.compile(
r'.+Found line ending with white spaces in[^*]+\*+\s+([^*]+)\*+.*',
re.M | re.S)
result = rex.match(output)
if result:
block = result.group(1)
filenames.extend(re.findall('(.+?), line [0-9]+', block))
if not filenames:
print Found no problem files
done_processing = {}
for filename in filenames:
if filename in done_processing:
print Already processed %s % filename
continue
done_processing[filename] = 1
f = open(filename, 'rb')
lines = f.readlines()
f.close()
f = open(filename, 'wb')
for line in lines:
line = line.rstrip()
f.write(line)
f.write('\n')
f.close()
print Finished processing %s % filename
On Wed, Nov 18, 2009 at 4:32 PM, Marc-Antoine Ruel mar...@chromium.org wrote:
First, I'd prefer to keep the presubmit checks from having any side-effect.
For a)
You haven't mentioned which editor you use but if it is a problem for
you, maybe you should tweak the editor? VS, emacs, vim can be modified
to do it or at least highlight it; I don't know about xcode. Otherwise
a very simple python script can do it for you, maybe you could create
a new kind of gcl hook. git already has functionality for commit
hooks.
For b), follow the steps at
http://dev.chromium.org/developers/coding-style#TOC-Subversion-properties
It's necessary for git usage too.
M-A
On Wed, Nov 18, 2009 at 4:26 PM, Dave MacLachlan dmacl...@google.com wrote:
Hey Marc-Antoine:
What would it take to have the presubmit scripts automagically do the
following:
a) Remove all whitespace at the end of .h, .c, .cc and .mm files?
b) Apply 'svn pset svn:eol-style LF' as necessary to .h, .c, .cc and .mm
files?
This would save me a great deal of time. My editor of choice does not take
care of getting rid of the whitespace for me.
Cheers,
Dave
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Heads up: safely ignored regression on Linux Startup perf test
I don't have an answer to that. The t_ref line didn't move either. On Wed, Nov 18, 2009 at 11:42 AM, Tony Chang t...@google.com wrote: Why didn't the black line on the linux warm perf bot change? It says that that is the extension_toolstrip50 test, which I would expect to run slower than the extension_toolstrip1 test. Maybe the graph is pulling the wrong numbers? http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warm On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek j...@chromium.orgwrote: Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.com wrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] huge binary drop of native client code
Arrgh. Sorry about that. There was some confusion as to which third_party directory those were suppose to go into (we really need to change gcl to base everything from the top of the world). Backing things out shortly. It didn't break nacl's trybots or waterfall because they're less pared down, and probably got thru a try job on mac by chance on the DEPs roll. I think the right way to avoid this in the future would be a common source size check in both nacl and chrome's PRESUBMIT.py I'll add such a thing shortly. Sorry, I believe I signed off on the original review in the nacl tree. -BradN On Wed, Nov 18, 2009 at 4:29 PM, Evan Martin e...@chromium.org wrote: It seems someone (not blaming them in particular) checked in 300mb of Windows 64 binaries in the native client tree. This check-in also seems to have hosed the trybots (they time out while attempting to fetch this data). A /b/slave/linux/build/src/native_client/src/third_party/mingw-w64/mingw-w64-src_20091116.tar.bz2 command timed out: 300 seconds without output, killing pid 15342 elapsedTime=978.505349 update failed, trying 4 more times after 300 seconds Rather than the obvious rant, I'd like to start a thread on something constructive: What can we do to protect our tree from this sort of thing in the future? - Do we need a trybot for NaCL trunk like we do for WebKit? - Would presubmit scripts help? (I guess that won't help since they're in DEPS?) - Could a style guide that prohibits checking in large binaries help reviewers catch this? - Any other ideas? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] huge binary drop of native client code
On Wed, Nov 18, 2009 at 4:43 PM, Bradley Nelson bradnel...@google.com wrote: Backing things out shortly. No rush; if you need the code, it's ok. (It'd be nice if you used deps_os though.) It didn't break nacl's trybots or waterfall because they're less pared down, and probably got thru a try job on mac by chance on the DEPs roll. I think the right way to avoid this in the future would be a common source size check in both nacl and chrome's PRESUBMIT.py I'll add such a thing shortly. Thank you! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] huge binary drop of native client code
Backed it out in the nacl tree and I've rolled the DEPS forward past it. It wasn't actually needed inside chrome (just for their sdk), but yes it should have been in a deps_os section too. Sorry again for the nuisance. -BradN On Wed, Nov 18, 2009 at 4:47 PM, Evan Martin e...@chromium.org wrote: On Wed, Nov 18, 2009 at 4:43 PM, Bradley Nelson bradnel...@google.com wrote: Backing things out shortly. No rush; if you need the code, it's ok. (It'd be nice if you used deps_os though.) It didn't break nacl's trybots or waterfall because they're less pared down, and probably got thru a try job on mac by chance on the DEPs roll. I think the right way to avoid this in the future would be a common source size check in both nacl and chrome's PRESUBMIT.py I'll add such a thing shortly. Thank you! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Splitting apart chrome.gyp
Hello All, I've just landed a change which splits src/chrome/chrome.gyp in to several pieces: chrome.gyp chrome_browser.gypi (browser) chrome_common.gypi (common) chrome_debugger.gypi (debugger) chrome_plugin.gypi (plugin) chrome_renderer.gypi (renderer) chrome_tests.gypi (almost all tests) You can treat these additional gypi's as if they were a part of chrome.gyp, everything is still relative to src/chrome. I'm not wedded to this division, but I've tried to carve off large enough chunks to reduce the contention on chrome.gyp. Because these are all gypi includes, nothing should change in the layout of the project files. -BradN -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
