DeArto20 | 1 Jan 15:00 2009
Picon

Problem with 'gcl' use.


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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Tommi | 1 Jan 15:21 2009
Picon

Re: Problem with 'gcl' use.

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 <sy3620 <at> gmail.com> 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 <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---

DeArto20 | 4 Jan 08:59 2009
Picon

Re: Problem with 'gcl' use.


test

On 1월1일, 오후11시00분, DeArto20 <sy3... <at> gmail.com> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

DeArto20 | 4 Jan 09:01 2009
Picon

Re: Problem with 'gcl' use.


It works fine. Thanks!!

On 1월1일, 오후11시21분, Tommi <to... <at> google.com> 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 <sy3... <at> gmail.com> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

DeArto20 | 4 Jan 09:03 2009
Picon

Re: Problem with 'gcl' use.


It works fine! Thanks!!

On 1월1일, 오후11시21분, Tommi <to... <at> google.com> 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 <sy3... <at> gmail.com> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

DeArto20 | 4 Jan 09:05 2009
Picon

Re: Problem with 'gcl' use.


It works fine. Thanks!!

On 1월1일, 오후11시21분, Tommi <to... <at> google.com> 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 <sy3... <at> gmail.com> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Brett Wilson | 4 Jan 20:08 2009

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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Mike Belshe | 4 Jan 20:28 2009
Picon

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 <brettw <at> chromium.org> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Brett Wilson | 4 Jan 21:12 2009

Re: V8Bindings_prebuild slowness


On Sun, Jan 4, 2009 at 11:28 AM, Mike Belshe <mbelshe <at> google.com> 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 <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Darin Fisher | 4 Jan 22:23 2009

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 <brettw <at> chromium.org> wrote:

On Sun, Jan 4, 2009 at 11:28 AM, Mike Belshe <mbelshe <at> google.com> 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 <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---


Gmane