Parameterization of an Android Build

Registered by Zach Pfeffer on 2011-10-12

In this session we will talk about plans to more effectively parameterize Android builds across kernels, toolchains, compiler flags, etc.

Blueprint information

Status:
Complete
Approver:
Zach Pfeffer
Priority:
Undefined
Drafter:
Bernhard Rosenkraenzer
Direction:
Needs approval
Assignee:
Bernhard Rosenkraenzer
Definition:
New
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Bernhard Rosenkraenzer on 2011-11-22
Completed by
Bernhard Rosenkraenzer on 2011-11-22

Related branches

Sprints

Whiteboard

In this session we will talk about plans to more effectively parameterize Android builds across kernels, toolchains, compiler flags, etc.

Description
------------------
Currently, the Android build system hardcodes compiler flags etc. in various Makefiles.

It would be better for us if we could override them in a build parameter, so we could get benchmarks on the effects of a compiler flag without modifying the Makefiles at every iteration.

Other things that could be parameterized:
- Parts of the kernel configuration (debug/profiling build vs. optimized build)
- Board specific bits to ease moving to a common source tree
- List of applications included (more or less stock Android vs. all development tools included vs. whatever)
- ...

Acceptance Criteria
-------------------------------
1. Identify further bits that should be parameterized
2. Discuss the best ways to do it

Agenda
------------
1. Give an overview of what it means to "parameterize" and Android build.
2. Create a list of variables we want to parameterize
3. Where we're going to store the configs
4. Gerrit
5. kconfig fragments

[pfalcon] Consider if we want not only parametrize more things, but also want to have builds spanning across array of parameter values. Setting and maintaining such manually won't scale. There's a "matrix build" feature in Jenkins allowing to structure/automate that. But using it will require restructuring android-build configuration approach (assuming the feature would do what we need, need additional research).

Goal of this Session
-----------------------------
Identify everything we'd like to have parameterized, and get some thoughts on the best approaches to do it

Notes:

Notes

Parameterization

Overide flags without modifying the source tree
Need to build manifest include mechanism
Kernel config should be pulled out, performance optimization
    .config fragment options
Toolchain and compiler version
    4.4, 4.5, 4.6
    matrix build feature?

AI: Paul Sokolovsky:

Michael Hope: Use Android as a test suite

Seperate config file may not be compatible with

Michael Hope: We have a special build system
   Lets standardize on variants and naming
       that's a -O3

AI: Michael Hope: Get name/compiler flags

AI: Cortex A9/Neon/ARM v5

AI: Paul Sokolovsky: Jenkins Matrix build
    Michael Hope: concerned about

Spec:
    Config file

Toolchain

Benchmarks

AI: Zach Pfeffer: Paramterize LAVA tests

AI: Zach Pfeffer: Infrastructure failures

AI: Zach Pfeffer: Spec200, Spec 2k6, Embassy

Compiler Errors

Every Linaro should be built with every

Tip, with tip, with tip
Tip vs. none

Toolchain for code generation
    Monkey Runner

Computed the right thing? Compiler errors

Toolchain for isis good
Toolchain regression
Toolchain for automated tests

We're interested in things we can control
    Not IO bound or Memory bound

Using Android as a test suite for your releases

android-eabi
gnu-linux

glibc
bionic - test suite

Is it faster or does it have a bug?

Correctness vs. performance

Test individual packages

Michael Hope builds 20-30 of the unit tests

AI: Zach Pfeffer: More hardware

Per-packages

AI: LAVA: hook up

Bero:
    What else do we want to parameterize?
        We have:
            kernel
            compiler
            flags
            tests
            applications

Packaging:
     What does

Configuration
     SHELL variables

Automate checkin
Automate history

(?)

Work Items