Fix the gn wrapper to be aware of the --root argument.

Fix the gn wrapper to be aware of the --root argument.

The gn binary itself is capable of being run from outside of a
checkout as long as you pass the --root flag.

However, the gn.py wrapper script needs to *also* know where the the
checkout is, in order to figure out how to find the gn binary itself.

This patch changes the wrapper to be aware of the --root arg :).

R=brettw@chromium.org
BUG=

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=259998

[brettw, 2014-03-27 21:04:20]

https://codereview.chromium.org/212173004/diff/20001/gn.py
File gn.py (right):

https://codereview.chromium.org/212173004/diff/20001/gn.py#newcode31
gn.py:31: # TODO(dpranke): It would be nice if '--root foo' worked in addition
I disagree that this should be supported and I'd just remove this todo. Normal
Unix command line parsing is either a single "-" with a single letter option and
no equal sign (optional space separating them) or a double "--" with an equal
sign. Chrome's command-line parsing follows this, so I don't see why GN should
be any different.

[brettw, 2014-03-27 21:04:29]

LGTM otherwise

[Dirk Pranke, 2014-03-27 21:39:01]

On 2014/03/27 21:04:20, brettw wrote:
> https://codereview.chromium.org/212173004/diff/20001/gn.py
> File gn.py (right):
> 
> https://codereview.chromium.org/212173004/diff/20001/gn.py#newcode31
> gn.py:31: # TODO(dpranke): It would be nice if '--root foo' worked in addition
> I disagree that this should be supported and I'd just remove this todo. Normal
> Unix command line parsing is either a single "-" with a single letter option
and
> no equal sign (optional space separating them) or a double "--" with an equal
> sign. Chrome's command-line parsing follows this, so I don't see why GN should
> be any different.

I'm happy to remove the TODO, but your statement about unix command line
conventions is partially wrong. long-style ("--") options aren't traditional
UNIX at all, they're GNU style (of course, this is a pedantic distinction at
this point).

More importantly, for GNU-style long options, "--include=foo" and "--include
foo" are both usually accepted and legal. The GNU coding standards are oddly
unclear on this, but docs for individual commands (like tar) are quite clear. I
believe gflags works this way as well, and certainly Pythonic arg parsing works
this way.

You're probably right that Chromium's arg parsing doesn't.

[Dirk Pranke, 2014-03-27 21:40:32]

The CQ bit was checked by dpranke@chromium.org

[commit-bot: I haz the power, 2014-03-27 21:42:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dpranke@chromium.org/212173004/40001

[commit-bot: I haz the power, 2014-03-27 21:44:38]

Change committed as 259998

[brettw, 2014-03-27 22:46:27]

On 2014/03/27 21:39:01, Dirk Pranke wrote:
> On 2014/03/27 21:04:20, brettw wrote:
> > https://codereview.chromium.org/212173004/diff/20001/gn.py
> > File gn.py (right):
> > 
> > https://codereview.chromium.org/212173004/diff/20001/gn.py#newcode31
> > gn.py:31: # TODO(dpranke): It would be nice if '--root foo' worked in
addition
> > I disagree that this should be supported and I'd just remove this todo.
Normal
> > Unix command line parsing is either a single "-" with a single letter option
> and
> > no equal sign (optional space separating them) or a double "--" with an
equal
> > sign. Chrome's command-line parsing follows this, so I don't see why GN
should
> > be any different.
> 
> I'm happy to remove the TODO, but your statement about unix command line
> conventions is partially wrong. long-style ("--") options aren't traditional
> UNIX at all, they're GNU style (of course, this is a pedantic distinction at
> this point).
> 
> More importantly, for GNU-style long options, "--include=foo" and "--include
> foo" are both usually accepted and legal. The GNU coding standards are oddly
> unclear on this, but docs for individual commands (like tar) are quite clear.
I
> believe gflags works this way as well, and certainly Pythonic arg parsing
works
> this way.
> 
> You're probably right that Chromium's arg parsing doesn't.

I looked at a bunch of Linux tools before posting my reply and the man page
listed the = as being required. It looks like the tar man page you specify
randomly specifies one or the other. It looks like they both accept either way
in practice. I still don't think we should change this.