Make gclient_utils.GetBuildtoolsPath() work in a build-spec checkout

Make gclient_utils.GetBuildtoolsPath() work in a build-spec checkout

This is required for gn.py to work properly on the Android official builders.

BUG=552040

[agrieve, 2015-11-25 21:04:36]

agrieve@chromium.org changed reviewers:
+ dpranke@chromium.org

[agrieve, 2015-11-25 21:04:36]

Not crazy about having to parse DEPS in a non-standard way, but don't see a
great alternative either.

Considered using:
gclient revinfo | grep buildtools

to find the subdirectory, but it takes 1.5s to run on my machine and that's too
slow to do before every gn invokation

[Dirk Pranke, 2015-11-25 21:42:05]

why do you need to invoke gn.py directly? i.e., why aren't you invoking MB
instead?

[agrieve, 2015-11-26 02:50:13]

On 2015/11/25 21:42:05, Dirk Pranke wrote:
> why do you need to invoke gn.py directly? i.e., why aren't you invoking MB
> instead?

Well, primarily because I hadn't considered using mb.

The two parts in the script where it's used are: http://shortn/_JaThx4LAKL and
http://shortn/_V3gCkK4VmL

With some quick testing, I couldn't see how to pass arbitrary gn args to mb
(seems like by design it doesn't want you to). But might be a bit weird to
encode build machine paths within config.mbl (e.g. for the whitelist generation
/ usage)

[dpranke, 2015-11-30 01:36:55]

On 2015/11/26 02:50:13, agrieve wrote:
> On 2015/11/25 21:42:05, Dirk Pranke wrote:
> > why do you need to invoke gn.py directly? i.e., why aren't you invoking MB
> > instead?
> 
> Well, primarily because I hadn't considered using mb.
> 
> The two parts in the script where it's used are: http://shortn/_JaThx4LAKL and
> http://shortn/_V3gCkK4VmL

Okay, if you were actually going to invoke GN directly in those scripts, I'd
just set the path to buildtools/linux64/gn ; it's not like we're going to move 
it any time soon.

> With some quick testing, I couldn't see how to pass arbitrary gn args to mb
> (seems like by design it doesn't want you to). But might be a bit weird to
> encode build machine paths within config.mbl (e.g. for the whitelist
generation
> / usage)

You're right that you can't pass arbitrary gn args to MB (and that is by
design),
though there is an exception, for the goma_dir . We could add more if
need be, though. 

It looks like the only things that are passed in as arbitrary strings are 
repack_whitelist and android_channel; is that right? 

Is repack_whitelist used in anything other than the official builds? If it
isn't, I'd be tempted to just hardcode the string if is_official_build==true.

android_channel probably can't be handled that way, though, and it's
not clear to me that there is a good way to handle it statically if we continue
to do multiple different types of builds from a single builder, but presumably
that's a much larger conversation.

To sum up: just invoke the binary directly from the scripts, and don't do
this change. Later, we need a different conversation about this script
as a whole (that you probably don't need to worry about too much).

[agrieve, 2015-12-02 19:13:16]

On 2015/11/30 01:36:55, dpranke wrote:
> On 2015/11/26 02:50:13, agrieve wrote:
> > On 2015/11/25 21:42:05, Dirk Pranke wrote:
> > > why do you need to invoke gn.py directly? i.e., why aren't you invoking MB
> > > instead?
> > 
> > Well, primarily because I hadn't considered using mb.
> > 
> > The two parts in the script where it's used are: http://shortn/_JaThx4LAKL
and
> > http://shortn/_V3gCkK4VmL
> 
> Okay, if you were actually going to invoke GN directly in those scripts, I'd
> just set the path to buildtools/linux64/gn ; it's not like we're going to move

> it any time soon.
> 
> > With some quick testing, I couldn't see how to pass arbitrary gn args to mb
> > (seems like by design it doesn't want you to). But might be a bit weird to
> > encode build machine paths within config.mbl (e.g. for the whitelist
> generation
> > / usage)
> 
> You're right that you can't pass arbitrary gn args to MB (and that is by
> design),
> though there is an exception, for the goma_dir . We could add more if
> need be, though. 
> 
> It looks like the only things that are passed in as arbitrary strings are 
> repack_whitelist and android_channel; is that right? 
> 
> Is repack_whitelist used in anything other than the official builds? If it
> isn't, I'd be tempted to just hardcode the string if is_official_build==true.
> 
> android_channel probably can't be handled that way, though, and it's
> not clear to me that there is a good way to handle it statically if we
continue
> to do multiple different types of builds from a single builder, but presumably
> that's a much larger conversation.
> 
> To sum up: just invoke the binary directly from the scripts, and don't do
> this change. Later, we need a different conversation about this script
> as a whole (that you probably don't need to worry about too much).

I think I came to the same conclusion last weekend and updated the script to
just use path/to/buildtools/linxu64/gn directly. Wrapper script probably needs
to be re-thought.