Add build target for inputview.

Add build target for inputview.

BUG=401729
Committed: https://crrev.com/10278398d654619a49331d980052576eb67119b4
Cr-Commit-Position: refs/heads/master@{#302275}

[kevers, 2014-10-28 17:51:11]

kevers@chromium.org changed reviewers:
+ bruthig@chromium.org

[kevers, 2014-10-28 17:54:05]

Hi Ben,

Can you please take a look at the Python scripts in this CL.

[bruthig, 2014-10-28 19:20:45]

Added some python insights and pointers.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
File third_party/google_input_tools/builder.py (right):

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:20: Scans Javascript file for provied
and required namespaces.
sp provied/provided

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:33: try:
An alternative (and more pythonic) way to the try/finally to ensure the file
will be closed would be:

with open(filename, 'r') as file_handle:
  for line in file_handle:
    if re.match(require_regex, line):
      requires.append(re.search(require_regex, line).group(1))
    if re.match(provide_regex, line):
      provides.append(re.search(provide_regex, line).group(1))
return provides, requires


Applies elsewhere too.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:34: for line in file_handle:
Is it correct to assume that all matches will be contained on a single line?  I
don't think this will work if they they can be broken across multiple lines...

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:36:
requires.append(re.search(require_regex, line).group(1))
You could replace the for loop and if statements with two python list
comprehensions like so:
requires = [re.search(require_regex, line).group(1) for line in file_handle if
re.match(require_regex, line)]
provides = [re.search(provide_regex, line).group(1) for line in file_handle if
re.match(provide_regex, line)]

This would be the more 'pythonic' way to do the same thing and I will leave it
as an exercise to decide which one is more readable.  I think the list
comprehension method might be faster because it can be optimized inside the
interpreter.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:74: well as 'proivde' and 'require'
statements are removed during to export to
sp proivde/provide
sp removed during to/the export

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:103: target_file.write('// %s\n' %
name)
If you care to make this platform agnostic you could use os.linesep instead of
'\n' to output a line separator.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:132: end_comment =
formatted.find('*/')
It might be more readable/maintainable if there was only one spot that looked
for the ending of a 'potentially' multi line comment instead of here and on line
114.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:137: if len(formatted.strip()) > 0:
The if statement below would be equivalent (assuming formatted.strip() would
never return a negative number).  Implicit bool checks call the __nonzero__
method which for strings will check it's length.

if formatted.strip():

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:153: return arguments[i + 1]
Is it intentional/ok that this will raise an out of bounds exception for the
following invalid arguments:
arguments=["--target"]

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:166: for i in range(len(arguments)):
[applies to Python2.6 only] If arguments is going to contain a large number of
items it would be more memory efficient to do a while loop because range(...)
actually constructs a list object.  In 3.2 range(...) returns an iterable and
this comment does not apply.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:180: target = GetTargetFile(sys.argv)
You may want to consider using pythons built in argparse library.  See
https://docs.python.org/2/library/argparse.html

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
File third_party/google_input_tools/update.py (right):

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/update.py:17: preamble = [
You could do
preamble = os.linesep.join(['Line1', 'Line2'])
and then you wouldn't have to loop over the list items when you are writing the
preamble out on line 219.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/update.py:215: 
I'm not 100% sure if it will work for the formatting you are trying to achieve
but it might be worth checking out the the json.dumps function.  That way you
could build up your python dict and lists and simply output the string and not
have to worry about matching braces or escaping special characters.

Example:
json_data= {'key1' : ['list_item1', 'list_item2'], 'key2' : 'value2']
json.dumps(json_data, sort_keys=True, indent=2, separators=(',', ': '))

[kevers, 2014-10-29 14:26:58]

kevers@chromium.org changed reviewers:
+ bshe@chromium.org

[kevers, 2014-10-29 14:27:20]

+bshe for coOWNERS

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
File third_party/google_input_tools/builder.py (right):

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:20: Scans Javascript file for provied
and required namespaces.
On 2014/10/28 19:20:44, bruthig wrote:
> sp provied/provided

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:33: try:
On 2014/10/28 19:20:44, bruthig wrote:
> An alternative (and more pythonic) way to the try/finally to ensure the file
> will be closed would be:
> 
> with open(filename, 'r') as file_handle:
>   for line in file_handle:
>     if re.match(require_regex, line):
>       requires.append(re.search(require_regex, line).group(1))
>     if re.match(provide_regex, line):
>       provides.append(re.search(provide_regex, line).group(1))
> return provides, requires
> 
> 
> Applies elsewhere too.

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:34: for line in file_handle:
On 2014/10/28 19:20:44, bruthig wrote:
> Is it correct to assume that all matches will be contained on a single line? 
I
> don't think this will work if they they can be broken across multiple lines...

A linebreak is not allowed within a require or provide statement.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:36:
requires.append(re.search(require_regex, line).group(1))
On 2014/10/28 19:20:44, bruthig wrote:
> You could replace the for loop and if statements with two python list
> comprehensions like so:
> requires = [re.search(require_regex, line).group(1) for line in file_handle if
> re.match(require_regex, line)]
> provides = [re.search(provide_regex, line).group(1) for line in file_handle if
> re.match(provide_regex, line)]
> 
> This would be the more 'pythonic' way to do the same thing and I will leave it
> as an exercise to decide which one is more readable.  I think the list
> comprehension method might be faster because it can be optimized inside the
> interpreter.

As this solution would loop over the file twice, I think I should leave it as
is.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:74: well as 'proivde' and 'require'
statements are removed during to export to
On 2014/10/28 19:20:44, bruthig wrote:
> sp proivde/provide
> sp removed during to/the export

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:103: target_file.write('// %s\n' %
name)
On 2014/10/28 19:20:44, bruthig wrote:
> If you care to make this platform agnostic you could use os.linesep instead of
> '\n' to output a line separator.

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:132: end_comment =
formatted.find('*/')
On 2014/10/28 19:20:44, bruthig wrote:
> It might be more readable/maintainable if there was only one spot that looked
> for the ending of a 'potentially' multi line comment instead of here and on
line
> 114.

This spot is looking for potentially multiple instances of an inline comments
rather than a multiline comment.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:137: if len(formatted.strip()) > 0:
On 2014/10/28 19:20:44, bruthig wrote:
> The if statement below would be equivalent (assuming formatted.strip() would
> never return a negative number).  Implicit bool checks call the __nonzero__
> method which for strings will check it's length.
> 
> if formatted.strip():

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:153: return arguments[i + 1]
On 2014/10/28 19:20:44, bruthig wrote:
> Is it intentional/ok that this will raise an out of bounds exception for the
> following invalid arguments:
> arguments=["--target"]

Removed in favor of options parser.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:166: for i in range(len(arguments)):
On 2014/10/28 19:20:44, bruthig wrote:
> [applies to Python2.6 only] If arguments is going to contain a large number of
> items it would be more memory efficient to do a while loop because range(...)
> actually constructs a list object.  In 3.2 range(...) returns an iterable and
> this comment does not apply.

Removed in favor of options parser.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/builder.py:180: target = GetTargetFile(sys.argv)
On 2014/10/28 19:20:44, bruthig wrote:
> You may want to consider using pythons built in argparse library.  See
> https://docs.python.org/2/library/argparse.html

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
File third_party/google_input_tools/update.py (right):

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/update.py:17: preamble = [
On 2014/10/28 19:20:44, bruthig wrote:
> You could do
> preamble = os.linesep.join(['Line1', 'Line2'])
> and then you wouldn't have to loop over the list items when you are writing
the
> preamble out on line 219.

Done.

https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
third_party/google_input_tools/update.py:215: 
On 2014/10/28 19:20:45, bruthig wrote:
> I'm not 100% sure if it will work for the formatting you are trying to achieve
> but it might be worth checking out the the json.dumps function.  That way you
> could build up your python dict and lists and simply output the string and not
> have to worry about matching braces or escaping special characters.
> 
> Example:
> json_data= {'key1' : ['list_item1', 'list_item2'], 'key2' : 'value2']
> json.dumps(json_data, sort_keys=True, indent=2, separators=(',', ': '))

Done.

[bruthig, 2014-10-29 15:19:48]

On 2014/10/29 14:27:20, kevers wrote:
> +bshe for coOWNERS
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> File third_party/google_input_tools/builder.py (right):
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:20: Scans Javascript file for
provied
> and required namespaces.
> On 2014/10/28 19:20:44, bruthig wrote:
> > sp provied/provided
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:33: try:
> On 2014/10/28 19:20:44, bruthig wrote:
> > An alternative (and more pythonic) way to the try/finally to ensure the file
> > will be closed would be:
> > 
> > with open(filename, 'r') as file_handle:
> >   for line in file_handle:
> >     if re.match(require_regex, line):
> >       requires.append(re.search(require_regex, line).group(1))
> >     if re.match(provide_regex, line):
> >       provides.append(re.search(provide_regex, line).group(1))
> > return provides, requires
> > 
> > 
> > Applies elsewhere too.
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:34: for line in file_handle:
> On 2014/10/28 19:20:44, bruthig wrote:
> > Is it correct to assume that all matches will be contained on a single line?

> I
> > don't think this will work if they they can be broken across multiple
lines...
> 
> A linebreak is not allowed within a require or provide statement.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:36:
> requires.append(re.search(require_regex, line).group(1))
> On 2014/10/28 19:20:44, bruthig wrote:
> > You could replace the for loop and if statements with two python list
> > comprehensions like so:
> > requires = [re.search(require_regex, line).group(1) for line in file_handle
if
> > re.match(require_regex, line)]
> > provides = [re.search(provide_regex, line).group(1) for line in file_handle
if
> > re.match(provide_regex, line)]
> > 
> > This would be the more 'pythonic' way to do the same thing and I will leave
it
> > as an exercise to decide which one is more readable.  I think the list
> > comprehension method might be faster because it can be optimized inside the
> > interpreter.
> 
> As this solution would loop over the file twice, I think I should leave it as
> is.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:74: well as 'proivde' and 'require'
> statements are removed during to export to
> On 2014/10/28 19:20:44, bruthig wrote:
> > sp proivde/provide
> > sp removed during to/the export
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:103: target_file.write('// %s\n' %
> name)
> On 2014/10/28 19:20:44, bruthig wrote:
> > If you care to make this platform agnostic you could use os.linesep instead
of
> > '\n' to output a line separator.
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:132: end_comment =
> formatted.find('*/')
> On 2014/10/28 19:20:44, bruthig wrote:
> > It might be more readable/maintainable if there was only one spot that
looked
> > for the ending of a 'potentially' multi line comment instead of here and on
> line
> > 114.
> 
> This spot is looking for potentially multiple instances of an inline comments
> rather than a multiline comment.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:137: if len(formatted.strip()) > 0:
> On 2014/10/28 19:20:44, bruthig wrote:
> > The if statement below would be equivalent (assuming formatted.strip() would
> > never return a negative number).  Implicit bool checks call the __nonzero__
> > method which for strings will check it's length.
> > 
> > if formatted.strip():
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:153: return arguments[i + 1]
> On 2014/10/28 19:20:44, bruthig wrote:
> > Is it intentional/ok that this will raise an out of bounds exception for the
> > following invalid arguments:
> > arguments=["--target"]
> 
> Removed in favor of options parser.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:166: for i in range(len(arguments)):
> On 2014/10/28 19:20:44, bruthig wrote:
> > [applies to Python2.6 only] If arguments is going to contain a large number
of
> > items it would be more memory efficient to do a while loop because
range(...)
> > actually constructs a list object.  In 3.2 range(...) returns an iterable
and
> > this comment does not apply.
> 
> Removed in favor of options parser.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/builder.py:180: target =
GetTargetFile(sys.argv)
> On 2014/10/28 19:20:44, bruthig wrote:
> > You may want to consider using pythons built in argparse library.  See
> > https://docs.python.org/2/library/argparse.html
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> File third_party/google_input_tools/update.py (right):
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/update.py:17: preamble = [
> On 2014/10/28 19:20:44, bruthig wrote:
> > You could do
> > preamble = os.linesep.join(['Line1', 'Line2'])
> > and then you wouldn't have to loop over the list items when you are writing
> the
> > preamble out on line 219.
> 
> Done.
> 
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> third_party/google_input_tools/update.py:215: 
> On 2014/10/28 19:20:45, bruthig wrote:
> > I'm not 100% sure if it will work for the formatting you are trying to
achieve
> > but it might be worth checking out the the json.dumps function.  That way
you
> > could build up your python dict and lists and simply output the string and
not
> > have to worry about matching braces or escaping special characters.
> > 
> > Example:
> > json_data= {'key1' : ['list_item1', 'list_item2'], 'key2' : 'value2']
> > json.dumps(json_data, sort_keys=True, indent=2, separators=(',', ': '))
> 
> Done.

LGTM

[bshe, 2014-10-29 19:11:19]

On 2014/10/29 15:19:48, bruthig wrote:
> On 2014/10/29 14:27:20, kevers wrote:
> > +bshe for coOWNERS
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > File third_party/google_input_tools/builder.py (right):
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:20: Scans Javascript file for
> provied
> > and required namespaces.
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > sp provied/provided
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:33: try:
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > An alternative (and more pythonic) way to the try/finally to ensure the
file
> > > will be closed would be:
> > > 
> > > with open(filename, 'r') as file_handle:
> > >   for line in file_handle:
> > >     if re.match(require_regex, line):
> > >       requires.append(re.search(require_regex, line).group(1))
> > >     if re.match(provide_regex, line):
> > >       provides.append(re.search(provide_regex, line).group(1))
> > > return provides, requires
> > > 
> > > 
> > > Applies elsewhere too.
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:34: for line in file_handle:
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > Is it correct to assume that all matches will be contained on a single
line?
> 
> > I
> > > don't think this will work if they they can be broken across multiple
> lines...
> > 
> > A linebreak is not allowed within a require or provide statement.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:36:
> > requires.append(re.search(require_regex, line).group(1))
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > You could replace the for loop and if statements with two python list
> > > comprehensions like so:
> > > requires = [re.search(require_regex, line).group(1) for line in
file_handle
> if
> > > re.match(require_regex, line)]
> > > provides = [re.search(provide_regex, line).group(1) for line in
file_handle
> if
> > > re.match(provide_regex, line)]
> > > 
> > > This would be the more 'pythonic' way to do the same thing and I will
leave
> it
> > > as an exercise to decide which one is more readable.  I think the list
> > > comprehension method might be faster because it can be optimized inside
the
> > > interpreter.
> > 
> > As this solution would loop over the file twice, I think I should leave it
as
> > is.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:74: well as 'proivde' and
'require'
> > statements are removed during to export to
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > sp proivde/provide
> > > sp removed during to/the export
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:103: target_file.write('// %s\n' %
> > name)
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > If you care to make this platform agnostic you could use os.linesep
instead
> of
> > > '\n' to output a line separator.
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:132: end_comment =
> > formatted.find('*/')
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > It might be more readable/maintainable if there was only one spot that
> looked
> > > for the ending of a 'potentially' multi line comment instead of here and
on
> > line
> > > 114.
> > 
> > This spot is looking for potentially multiple instances of an inline
comments
> > rather than a multiline comment.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:137: if len(formatted.strip()) >
0:
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > The if statement below would be equivalent (assuming formatted.strip()
would
> > > never return a negative number).  Implicit bool checks call the
__nonzero__
> > > method which for strings will check it's length.
> > > 
> > > if formatted.strip():
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:153: return arguments[i + 1]
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > Is it intentional/ok that this will raise an out of bounds exception for
the
> > > following invalid arguments:
> > > arguments=["--target"]
> > 
> > Removed in favor of options parser.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:166: for i in
range(len(arguments)):
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > [applies to Python2.6 only] If arguments is going to contain a large
number
> of
> > > items it would be more memory efficient to do a while loop because
> range(...)
> > > actually constructs a list object.  In 3.2 range(...) returns an iterable
> and
> > > this comment does not apply.
> > 
> > Removed in favor of options parser.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/builder.py:180: target =
> GetTargetFile(sys.argv)
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > You may want to consider using pythons built in argparse library.  See
> > > https://docs.python.org/2/library/argparse.html
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > File third_party/google_input_tools/update.py (right):
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/update.py:17: preamble = [
> > On 2014/10/28 19:20:44, bruthig wrote:
> > > You could do
> > > preamble = os.linesep.join(['Line1', 'Line2'])
> > > and then you wouldn't have to loop over the list items when you are
writing
> > the
> > > preamble out on line 219.
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/676423003/diff/20001/third_party/google_input...
> > third_party/google_input_tools/update.py:215: 
> > On 2014/10/28 19:20:45, bruthig wrote:
> > > I'm not 100% sure if it will work for the formatting you are trying to
> achieve
> > > but it might be worth checking out the the json.dumps function.  That way
> you
> > > could build up your python dict and lists and simply output the string and
> not
> > > have to worry about matching braces or escaping special characters.
> > > 
> > > Example:
> > > json_data= {'key1' : ['list_item1', 'list_item2'], 'key2' : 'value2']
> > > json.dumps(json_data, sort_keys=True, indent=2, separators=(',', ': '))
> > 
> > Done.
> 
> LGTM

lgtm

[kevers, 2014-10-29 20:37:06]

The CQ bit was checked by kevers@chromium.org

[commit-bot: I haz the power, 2014-10-29 20:37:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/676423003/40001

[commit-bot: I haz the power, 2014-10-29 21:14:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-29 21:14:54]

Try jobs failed on following builders:
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[kevers, 2014-10-31 13:45:43]

Biao and Ben,

Can I please get a second review. Latest patch touches every file.  Hitting
command line length limitations on some bots and switched to reading sources
from a json file.  Add support for GN builds.

[bshe, 2014-10-31 14:28:24]

On 2014/10/31 13:45:43, kevers wrote:
> Biao and Ben,
> 
> Can I please get a second review. Latest patch touches every file.  Hitting
> command line length limitations on some bots and switched to reading sources
> from a json file.  Add support for GN builds.

lgtm

[bruthig, 2014-10-31 14:42:52]

On 2014/10/31 13:45:43, kevers wrote:
> Biao and Ben,
> 
> Can I please get a second review. Latest patch touches every file.  Hitting
> command line length limitations on some bots and switched to reading sources
> from a json file.  Add support for GN builds.

lgtm

[kevers, 2014-10-31 15:18:23]

The CQ bit was checked by kevers@chromium.org

[commit-bot: I haz the power, 2014-10-31 15:19:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/676423003/100001

[commit-bot: I haz the power, 2014-10-31 15:55:28]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2014-10-31 15:56:27]

Patchset 6 (id:??) landed as
https://crrev.com/10278398d654619a49331d980052576eb67119b4
Cr-Commit-Position: refs/heads/master@{#302275}