platform_build_kati, branch oreo-vts-release

Merge remote-tracking branch 'aosp/upstream' into master am: 341a2ceccb am: 4124b98e2f

2017-02-24T08:57:31+00:00

am: cfcb823d2f

Change-Id: I4f773ef61816d1b79950264cb88fb9be1454e5cd

Merge remote-tracking branch 'aosp/upstream' into master am: 341a2ceccb

2017-02-24T08:55:01+00:00

am: 4124b98e2f

Change-Id: I2e4ef9e03c99b335629063655f231c0ce18a53f5

Merge remote-tracking branch 'aosp/upstream' into master

2017-02-24T08:52:02+00:00

am: 341a2ceccb

Change-Id: I4aae5b2b678f9a9a35dc2e91bb53664fa3238c7b

Merge remote-tracking branch 'aosp/upstream' into master

2017-02-24T04:43:32+00:00

* aosp/upstream:
  Randomize cpu affinity
  Be more resilient to directories disappearing during startup
  Pass a Loc into FindEmulator for better warnings
  Add --color_warnings to make warnings/errors like clang
  [AUTHORS] Fix kati instead of glog
  Add Koichi Shiraishi to AUTHORS/CONTRIBUTORS
  [C++] add +build ignore magic comment for go build
  [go] fix ldflags foramt to add '=' for -X flag
  [go] fix stat.Dev type to uint64
  Allow rules to specify custom ninja pools
  Fix some possible performance issues found by clang-tidy

Test: kati tests
Test: multiproduct_build on aosp
Change-Id: I4c427dde2bb9d1a0970e97d1e822e093bd269dfe

Merge pull request #112 from danw/random_affinity

2017-02-24T04:40:22+00:00

Randomize cpu affinity

Merge pull request #113 from danw/resilient_find

2017-02-24T03:29:55+00:00

Be more resilient to directories disappearing during startup

Randomize cpu affinity

2017-02-24T02:41:50+00:00

Continue to lock kati to one or two CPUs, but pick one CPU at random,
and pick another CPU next to it. This dramatically speeds up cases where
more than one Kati instance is running at a time.

There's a multiproduct_build tool in Android that attempts to run Kati
on every build configuration present in the tree. My machine has 48
(including hyperthreading) cpu cores, with 64GB of ram. Before this
change, it would take ~12 minutes to build all 59 configurations, 12 at
a time. After this change it takes 3 minutes.

There doesn't seem to be any significant change in timings for
standalone builds. It looks like there was 1-2% difference with my
previous change that chose two completely random CPUs, but choosing two
that are likely hyperthreaded, or at least on the same chip helps.

Merge pull request #111 from danw/color_warnings

2017-02-23T20:56:39+00:00

Improve and color warnings (with --color_warnings)

Be more resilient to directories disappearing during startup

2017-02-23T08:27:57+00:00

In multiproduct_build, we run a lot of kati instances in the same source
tree, but pointing to different out folders. I'm removing the out
folders of successful runs so that too much disk space isn't used
(unless the user requests it). But I often see a kati PERROR about
opendir failing, since it's trying to set up the find emulator while a
different configuration's output directory is being removed.

This was also hit by #109 in similar circumstances.

Pass a Loc into FindEmulator for better warnings

2017-02-23T06:42:02+00:00

Before this change, we'd only get a warning from FindEmulator, with no
idea which makefile caused it:

  FindEmulator: find: `tests': No such file or directory

With this change, we'll get a better idea of which line triggered that
problem:

  cts/tests/tests/content/Android.mk:43: FindEmulator: find: `test': No such file or directory

And it will be colorized like any other location-based warning with the
previous patch if --color_warnings is turned on.