Handles unknown TARGET_PRODUCT in envsetup.sh

Handles unknown TARGET_PRODUCT in envsetup.sh

Android comes with a set of build target products (such as soju, trygon)
to build and run Chrome for Android on. When it gets ported to other devices,
however, the build env will likely have its own build targets for them, unknown
to pre-defined build environment.

This CL tries to let Chrome for Android build env support those unknown target
products. Rather than bloating the env setup script with those new target names,
it tries getting TARGET_ARCH_VARIANT by calling the function get_build_var()
(if available) defined in ${ANDROID_ROOT}/build/envsetup.sh to see if the
variable was set up by lunch command. This will help Chrome for Android build
for new, upcoming devices.

TEST=Built successfully with following targets:
      - soju(armv7-a-neon)
      - trygon(arm7-a)
      - full(armv5te)
      - full_x86(x86)
      - a custom target whose TARGET_ARCH_VARIANT is armv7-a

BUG=

[Yaron, 2012-10-18 19:55:08]

seems reasonable to me but +joth whom I believe was talking about doing
something similar.

[joth, 2012-10-18 20:12:41]

+bulach
I think the suggestion was to remove the list of 'supported' products and just
have one entry for arm and another for x86. (see downstream discussion on 
http://go/ocoxk)

[Jinsuk Kim (do not use this), 2012-10-19 07:10:14]

Well then I hope this CL could be a stopgap measure for it. I'm ok to work on
for further changes towards the direction. My team uses a unknown target product
names, which I believe makes me an ideal person to handle it. Thanks.

On 2012/10/18 20:12:41, joth wrote:
> +bulach
> I think the suggestion was to remove the list of 'supported' products and just
> have one entry for arm and another for x86. (see downstream discussion on 
> http://go/ocoxk)

[Jinsuk Kim (do not use this), 2012-10-23 01:22:18]

How about adding tech_arch= (or cpu=) param to envsetup.sh like following?

. build/android/envsetup.sh  # defaults to arm
. build/android/envsetup.sh --tech_arch=x86
. build/android/envsetup.sh --help
build/android/envsetup.sh [options]
  --help: show this help
  --tech_arch: specifies the cpu type. supported types: arm, x86
        Default is arm
   

On 2012/10/19 07:10:14, jinsukkim wrote:
> Well then I hope this CL could be a stopgap measure for it. I'm ok to work on
> for further changes towards the direction. My team uses a unknown target
product
> names, which I believe makes me an ideal person to handle it. Thanks.
> 
> On 2012/10/18 20:12:41, joth wrote:
> > +bulach
> > I think the suggestion was to remove the list of 'supported' products and
just
> > have one entry for arm and another for x86. (see downstream discussion on 
> > http://go/ocoxk)

[Jinsuk Kim (do not use this), 2012-10-23 01:25:38]

s/tech_arch/target_arch/g

On 2012/10/23 01:22:18, jinsukkim wrote:
> How about adding tech_arch= (or cpu=) param to envsetup.sh like following?
> 
> . build/android/envsetup.sh  # defaults to arm
> . build/android/envsetup.sh --tech_arch=x86
> . build/android/envsetup.sh --help
> build/android/envsetup.sh [options]
>   --help: show this help
>   --tech_arch: specifies the cpu type. supported types: arm, x86
>         Default is arm
>    
> 
> On 2012/10/19 07:10:14, jinsukkim wrote:
> > Well then I hope this CL could be a stopgap measure for it. I'm ok to work
on
> > for further changes towards the direction. My team uses a unknown target
> product
> > names, which I believe makes me an ideal person to handle it. Thanks.
> > 
> > On 2012/10/18 20:12:41, joth wrote:
> > > +bulach
> > > I think the suggestion was to remove the list of 'supported' products and
> just
> > > have one entry for arm and another for x86. (see downstream discussion on 
> > > http://go/ocoxk)

[bulach, 2012-10-23 13:49:45]

agreed, sounds reasonable! thanks! I'm cc:ing navabi as well, as it may have
some implications on some his bots..

[Jinsuk Kim (do not use this), 2012-10-24 04:51:08]

On 2012/10/23 13:49:45, bulach wrote:
> agreed, sounds reasonable! thanks! I'm cc:ing navabi as well, as it may have
> some implications on some his bots..

Created a new CL https://codereview.chromium.org/11260008 that addresses the
point made here. Thanks.