[chromium-dev] Re: Problem with 'gcl' use.
test On 1월1일, 오후11시00분, DeArto20 wrote: > Hi. > > I have a problem during 'request review'. > > Specifically, when i execute 'gcl change XXX' in the command window, I > get the following result. > > "gcl run outside of repository" > > How can i solve this problem. Plz let me know what should i do. > > Have a good day! --~--~-~--~~~---~--~~ 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: Problem with 'gcl' use.
It works fine. Thanks!! On 1월1일, 오후11시21분, Tommi wrote: > Hey DeArto20, > > Try running gcl from the src directory. For me that's C:\chromium\src. > > On Thu, Jan 1, 2009 at 2:00 PM, DeArto20 wrote: > > > Hi. > > > I have a problem during 'request review'. > > > Specifically, when i execute 'gcl change XXX' in the command window, I > > get the following result. > > > "gcl run outside of repository" > > > How can i solve this problem. Plz let me know what should i do. > > > Have a good day! --~--~-~--~~~---~--~~ 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: Problem with 'gcl' use.
It works fine! Thanks!! On 1월1일, 오후11시21분, Tommi wrote: > Hey DeArto20, > > Try running gcl from the src directory. For me that's C:\chromium\src. > > On Thu, Jan 1, 2009 at 2:00 PM, DeArto20 wrote: > > > Hi. > > > I have a problem during 'request review'. > > > Specifically, when i execute 'gcl change XXX' in the command window, I > > get the following result. > > > "gcl run outside of repository" > > > How can i solve this problem. Plz let me know what should i do. > > > Have a good day! --~--~-~--~~~---~--~~ 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: Problem with 'gcl' use.
It works fine. Thanks!! On 1월1일, 오후11시21분, Tommi wrote: > Hey DeArto20, > > Try running gcl from the src directory. For me that's C:\chromium\src. > > On Thu, Jan 1, 2009 at 2:00 PM, DeArto20 wrote: > > > Hi. > > > I have a problem during 'request review'. > > > Specifically, when i execute 'gcl change XXX' in the command window, I > > get the following result. > > > "gcl run outside of repository" > > > How can i solve this problem. Plz let me know what should i do. > > > Have a good day! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] V8Bindings_prebuild slowness
I have been doing some build profiling over the weekend. When I run IncrediBuild, computing dependencies takes about 30 seconds. Then one CPU starts "performing custom build step" which is V8Bindings_prebuild. In parallel, most dependencies like ICU compile in the next minute. Then it hangs for 3 minutes waiting for V8Bindings_prebuild. Then it compiles all of WebCore and some remaining parts of Chrome in the next 4 minutes, and links in 2 minutes. Why is 1/3 of my time wasted waiting for a makefile to run? During this time I see a continuous stream of sh.exe, perl.exe, and cc1plus.exe getting spawned and killed. Looking at the makefile, this happens >300 times, and each time perl has to search a bunch of different directories of WebCore sources to find the file in question. If I already have this step completed, IncrediBuild can compile all of chrome_exe from scratch in 5:50 on my computer, which is really fast! With a clean debug directory, it takes 8:57. It seems like this is a really big waste of everybody's time. I don't entirely know what's going on, and I barely know Perl, but it seems like there are two options: 1) Improve the step to list the exact locations of each file, and to only run perl once, iterating over the list in perl rather than in the makefile. This loses the incremental aspect if you do change anything, but most people aren't changing the IDL files. I bet this would make it orders of magnitude faster. 2) Check in prebuilt V8 bindings. This means that the WebKit merger would need to run an extra step, but everything would magically work for everbody else. I really like this solution because I think the V8 bindings are the most common thing that causes weird build errors when you sync after a new WebKit has been pulled, and I think it's also the main reason that you have to physically delete the output directory instead of doing a regular clean. It could be that having the correct versions checked in saves everybody a lot of rebuilding in addition to saving several minutes on each build. I really like option #2. Does anybody have any thoughts on how well this would work? 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] Re: V8Bindings_prebuild slowness
It's been this way for a while; the good news is that it should only happen on initial build; subsequent builds don't regenerate the bindings. If 3 minutes is really too much for a full build, we could do your #2; hopefully the dependency checker would be smart enough not to rebuild them if they were checked in. We'd have to find where to check them in as well, because currently they are built into the output directory (for both Release and Debug; perhaps we could just generate one set, as I don't think they differ between release/debug builds) Mike On Sun, Jan 4, 2009 at 11:08 AM, Brett Wilson wrote: > > I have been doing some build profiling over the weekend. When I run > IncrediBuild, computing dependencies takes about 30 seconds. Then one > CPU starts "performing custom build step" which is > V8Bindings_prebuild. In parallel, most dependencies like ICU compile > in the next minute. > > Then it hangs for 3 minutes waiting for V8Bindings_prebuild. > > Then it compiles all of WebCore and some remaining parts of Chrome in > the next 4 minutes, and links in 2 minutes. > > Why is 1/3 of my time wasted waiting for a makefile to run? During > this time I see a continuous stream of sh.exe, perl.exe, and > cc1plus.exe getting spawned and killed. Looking at the makefile, this > happens >300 times, and each time perl has to search a bunch of > different directories of WebCore sources to find the file in question. > > If I already have this step completed, IncrediBuild can compile all of > chrome_exe from scratch in 5:50 on my computer, which is really fast! > With a clean debug directory, it takes 8:57. It seems like this is a > really big waste of everybody's time. I don't entirely know what's > going on, and I barely know Perl, but it seems like there are two > options: > > 1) Improve the step to list the exact locations of each file, and to > only run perl once, iterating over the list in perl rather than in the > makefile. This loses the incremental aspect if you do change anything, > but most people aren't changing the IDL files. I bet this would make > it orders of magnitude faster. > > 2) Check in prebuilt V8 bindings. This means that the WebKit merger > would need to run an extra step, but everything would magically work > for everbody else. I really like this solution because I think the V8 > bindings are the most common thing that causes weird build errors when > you sync after a new WebKit has been pulled, and I think it's also the > main reason that you have to physically delete the output directory > instead of doing a regular clean. It could be that having the correct > versions checked in saves everybody a lot of rebuilding in addition to > saving several minutes on each build. > > I really like option #2. Does anybody have any thoughts on how well > this would work? > > 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] Re: V8Bindings_prebuild slowness
On Sun, Jan 4, 2009 at 11:28 AM, Mike Belshe wrote: > It's been this way for a while; the good news is that it should only > happen on initial build; subsequent builds don't regenerate the > bindings. The problem is that I (and it seems like many other people) have learned that you have to do a full build basically every time you sync, because the dependencies aren't computed properly. Ironically the biggest problem of incorrect dependencies is the generated files! That's why I was suggesting the solution that will help both of these problems. If 3 minutes is really too much for a full build, we could > do your #2; hopefully the dependency checker would be smart enough not > to rebuild them if they were checked in. We'd have to find where to > check them in as well, because currently they are built into the > output directory (for both Release and Debug; perhaps we could just > generate one set, as I don't think they differ between release/debug > builds) I think we would need a new DEPS entry for them. Ojan's WebKit sync script could probably do the management of this automatically. 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] Re: V8Bindings_prebuild slowness
On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher wrote: > This problem could also be solved by ignoring DerivedSources.make, and > instead just add the "source" files to the vcproj. Then write a custom > .rules file for each file type that runs the appropriate batch command to > create the generated file. Then, dependency tracking would work just as it > does for .cpp files. Well, but you'd still have the slowness of spawing perl hundreds of times. I'm not sure that would speed up the build at all (though it would improve the dependency management). > Our DerivedSources.make is already so tremendously out of sync with the one > upstream that there doesn't seem to be much point in using it. I agree. 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] Re: V8Bindings_prebuild slowness
This problem could also be solved by ignoring DerivedSources.make, and instead just add the "source" files to the vcproj. Then write a custom .rules file for each file type that runs the appropriate batch command to create the generated file. Then, dependency tracking would work just as it does for .cpp files. Our DerivedSources.make is already so tremendously out of sync with the one upstream that there doesn't seem to be much point in using it. -Darin On Sun, Jan 4, 2009 at 3:12 PM, Brett Wilson wrote: > > On Sun, Jan 4, 2009 at 11:28 AM, Mike Belshe wrote: > > It's been this way for a while; the good news is that it should only > > happen on initial build; subsequent builds don't regenerate the > > bindings. > > The problem is that I (and it seems like many other people) have > learned that you have to do a full build basically every time you > sync, because the dependencies aren't computed properly. Ironically > the biggest problem of incorrect dependencies is the generated files! > That's why I was suggesting the solution that will help both of these > problems. > > > If 3 minutes is really too much for a full build, we could > > do your #2; hopefully the dependency checker would be smart enough not > > to rebuild them if they were checked in. We'd have to find where to > > check them in as well, because currently they are built into the > > output directory (for both Release and Debug; perhaps we could just > > generate one set, as I don't think they differ between release/debug > > builds) > > I think we would need a new DEPS entry for them. Ojan's WebKit sync > script could probably do the management of this automatically. > > 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] Re: V8Bindings_prebuild slowness
On Sun, Jan 4, 2009 at 4:45 PM, Brett Wilson wrote: > Well, but you'd still have the slowness of spawing perl hundreds of > times. I'm not sure that would speed up the build at all (though it > would improve the dependency management). Perhaps we've outgrown perl :-). I haven't looked at what the perl code does (I've been willfully ignoring v8, since it has been "just working" :-)), but is it something that a chunk of C++ linked against PCRE and knows how to iterate directories and stat file times could do? --Amanda --~--~-~--~~~---~--~~ 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: V8Bindings_prebuild slowness
I have wanted to check in the generated binding source for a long time (there is a bug on it). The benefit of checking it in is then it's visible from the source server, now you won't get the bindings source when source debugging w/ the symbol / source server. b/1346719 -- dean On Sun, Jan 4, 2009 at 11:38 PM, Amanda Walker wrote: > > On Sun, Jan 4, 2009 at 4:45 PM, Brett Wilson wrote: >> Well, but you'd still have the slowness of spawing perl hundreds of >> times. I'm not sure that would speed up the build at all (though it >> would improve the dependency management). > > Perhaps we've outgrown perl :-). I haven't looked at what the perl > code does (I've been willfully ignoring v8, since it has been "just > working" :-)), but is it something that a chunk of C++ linked against > PCRE and knows how to iterate directories and stat file times could > do? > > --Amanda > > > > --~--~-~--~~~---~--~~ 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: V8Bindings_prebuild slowness
The perl code is the upstream webkit's IDL compiler (but heavily modified for v8). It reads in the IDL files and generates the .h / .cpp files that are the actual binding code. It would be nice to rewrite this, but it would be a lot of work and also would need coordination upstream. On Sun, Jan 4, 2009 at 11:38 PM, Amanda Walker wrote: > > On Sun, Jan 4, 2009 at 4:45 PM, Brett Wilson wrote: >> Well, but you'd still have the slowness of spawing perl hundreds of >> times. I'm not sure that would speed up the build at all (though it >> would improve the dependency management). > > Perhaps we've outgrown perl :-). I haven't looked at what the perl > code does (I've been willfully ignoring v8, since it has been "just > working" :-)), but is it something that a chunk of C++ linked against > PCRE and knows how to iterate directories and stat file times could > do? > > --Amanda > > > > --~--~-~--~~~---~--~~ 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: V8Bindings_prebuild slowness
On Sun, Jan 4, 2009 at 5:40 PM, Dean McNamee wrote: > The perl code is the upstream webkit's IDL compiler (but heavily > modified for v8). It reads in the IDL files and generates the .h / > .cpp files that are the actual binding code. It would be nice to > rewrite this, but it would be a lot of work and also would need > coordination upstream. OK, makes sense. There would certainly be a certain amount of up-front work (and as I said, I haven't looked at it, so I don't know how much work that might be). Though if we're maintaining our own heavily modified version, it sounds like we're already paying a "having to coordinate our version with upstream webkit" price. I've ended up in the habit of doing clobber builds fairly often in Windows, thanks to the broken dependency tracking (and the fact that I only update my windows tree once or twice a week), so I share some of Brett's frustration (though my time ratios aren't as big, since we don't have the benefit of incredibuild out here). --Amanda --~--~-~--~~~---~--~~ 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: V8Bindings_prebuild slowness
On Sun, 4 Jan 2009, Brett Wilson wrote: > > On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher wrote: > > This problem could also be solved by ignoring DerivedSources.make, and > > instead just add the "source" files to the vcproj. Then write a custom > > .rules file for each file type that runs the appropriate batch command to > > create the generated file. Then, dependency tracking would work just as it > > does for .cpp files. > > Well, but you'd still have the slowness of spawing perl hundreds of > times. I'm not sure that would speed up the build at all (though it > would improve the dependency management). But you would only pay it once. Using native vcproj files may get the dependencies right and maybe you wouldn't need to do a full rebuild after each sync then. Or maybe I put too much faith in MSVC's dependency management. > > Our DerivedSources.make is already so tremendously out of sync with the one > > upstream that there doesn't seem to be much point in using it. > > I agree. It's not used in the scons build which properly tracks dependencies so the files are only generated once. Would Incredibuild be able to parallelize the perl scripts or does it only know how to parallelize c++ compiles? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Platform-dependent form control rendering in layout tests
I just upgraded my dev box to one of the new quad-cores and put Vista 64 on it so I can use more memory for the disk cache. (Note: XP64 isn't one of the standard corp OS images.) I suspect more people will want to start doing this (I'm still doing tests, will send out the results). I just realized that I have a problem now: I have no way to run webkit pixel tests since the form control reference images all require XP's Luna theme. I have three boxes: Vista, Mac, and Linux, so it's not reasonable to get another one. It also seems impossible to require everybody use XP forever. WebKit solves this by putting the layout test results of each build in a public place on the buildbot (I don't think ours are, are they?) and when you change something that has a reference that isn't for your system, you just grab it off there, double-check that it's correct, and check it in. However, this requires more tolerance of test redness than we have had so far. The other option is to use platform-independent form control rendering. This actually isn't too hard. WebKit already has form control rendering for when you have funky CSS styles applied (think when you set "border-top:2px solid red;" on a text fiend) and we can enable this easily enough in our theme control by returning the correct values (maybe there are a few edge cases that need cleaning up). This has the advantage of letting people running XP, Vista or either of those with the classic theme run the layout tests in a meaningful way. It has the disadvantage that none of our native theme rendering will be covered by pixel tests, which could lead to regressions. I'm not sure which approach is better. Does anybody have any thoughts? 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] Re: Platform-dependent form control rendering in layout tests
Can you grab the pixel results from the try server? On Sun, Jan 4, 2009 at 10:14 PM, Brett Wilson wrote: > > I just upgraded my dev box to one of the new quad-cores and put Vista > 64 on it so I can use more memory for the disk cache. (Note: XP64 > isn't one of the standard corp OS images.) I suspect more people will > want to start doing this (I'm still doing tests, will send out the > results). > > I just realized that I have a problem now: I have no way to run webkit > pixel tests since the form control reference images all require XP's > Luna theme. I have three boxes: Vista, Mac, and Linux, so it's not > reasonable to get another one. It also seems impossible to require > everybody use XP forever. > > WebKit solves this by putting the layout test results of each build in > a public place on the buildbot (I don't think ours are, are they?) and > when you change something that has a reference that isn't for your > system, you just grab it off there, double-check that it's correct, > and check it in. However, this requires more tolerance of test redness > than we have had so far. > > The other option is to use platform-independent form control > rendering. This actually isn't too hard. WebKit already has form > control rendering for when you have funky CSS styles applied (think > when you set "border-top:2px solid red;" on a text fiend) and we can > enable this easily enough in our theme control by returning the > correct values (maybe there are a few edge cases that need cleaning > up). > > This has the advantage of letting people running XP, Vista or either > of those with the classic theme run the layout tests in a meaningful > way. It has the disadvantage that none of our native theme rendering > will be covered by pixel tests, which could lead to regressions. > > I'm not sure which approach is better. Does anybody have any thoughts? > > Brett > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
