Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
http://source.android.com/source/building.html
...and we add all the tests that LAVA would call and all the results parsing to the builds.
What this would do is:
1. Allow all builds to be reproduced exactly using a git and a commit or branch. Since everything's baked into the build all the config, tests, everything is reproduced exactly. 2. Allow us to remove a bunch of documentation on how to do specific builds 3. Unify builds in the cloud and local builds
Ideas, thoughts?
On Tue, Jun 12, 2012 at 7:39 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
The only thing I am not sure about is that I still haven't seen an official instruction that would build a full platform - including the kernel... so whatever we do, we might have slightly deviated way of doing things as we produce a fully bootable system
In general I agree though that sticking to the pristine upstream instructions is a worthwhile goal.
...and we add all the tests that LAVA would call and all the results parsing to the builds.
I liked the idea of having the build produce a test manifest (e.g. a flat file with test names included) that is shipped inside or even outside the image. On top we would like to have a standard way to run tests by name. With that we could allow LAVA and developerse to run the same tests using the same tools.
So first: is there such a solution for AOSP already? Do they have a generic way to invoke "AOSP" tests by name?
If not, can we get a smart magic build system patch that produces such a test manifest?
Also, how hard is it to provide a simple host tool that would make it damn easy to run test XXX on a target connected?
On 12 June 2012 12:48, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 7:39 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
The only thing I am not sure about is that I still haven't seen an official instruction that would build a full platform - including the kernel... so whatever we do, we might have slightly deviated way of doing things as we produce a fully bootable system
What do you mean. The kernel is built as part of the platform, like it is today.
In general I agree though that sticking to the pristine upstream instructions is a worthwhile goal.
I think you misunderstood. All I want to do is to allow people to build Android using the instructions listed on android.com. These would be:
source build/envsetup.sh lunch full_panda-eng
instead of:
wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la...
tar -jxvf android-toolchain-eabi-linaro-*
export NUM_PROC=`getconf _NPROCESSORS_ONLN`
make -j${NUM_PROC} HOST_CC=gcc-4.7 HOST_CPP=cpp-4.7 HOST_CXX=g++-4.7 TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_TOOLS_PREFIX=/path/to/toolchain/arm-linux-androideabi- boottarball systemtarball userdatatarball showcommands > build_log_YYMMDD.txt 2>&1 &
...and we add all the tests that LAVA would call and all the results parsing to the builds.
I liked the idea of having the build produce a test manifest (e.g. a flat file with test names included) that is shipped inside or even outside the image. On top we would like to have a standard way to run tests by name. With that we could allow LAVA and developerse to run the same tests using the same tools.
I think this is way easier. When LAVA runs the test it just kicks off well named script and the script takes it from there.
So first: is there such a solution for AOSP already? Do they have a generic way to invoke "AOSP" tests by name?
Yeah, you send intents to them on the command line via adb.
If not, can we get a smart magic build system patch that produces such a test manifest?
I don't think we need a seperate test manifest. We just need a set of test gits that we include in the single manifest. Then things are all in one place.
Also, how hard is it to provide a simple host tool that would make it damn easy to run test XXX on a target connected?
Well you can just send an intent on the command line to a test entry point. You could wrap this with a little script.
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Tue, Jun 12, 2012 at 8:59 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 12 June 2012 12:48, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 7:39 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
The only thing I am not sure about is that I still haven't seen an official instruction that would build a full platform - including the kernel... so whatever we do, we might have slightly deviated way of doing things as we produce a fully bootable system
What do you mean. The kernel is built as part of the platform, like it is today.
IIRC, in gingerbread AOSP there was no manifest with a kernel inside. Hence whatever you did with lunch and munch you didn't end up with a bootable image.
Maybe they have a manifest with kernel for panda by now?
In general I agree though that sticking to the pristine upstream instructions is a worthwhile goal.
I think you misunderstood. All I want to do is to allow people to build Android using the instructions listed on android.com. These would be:
source build/envsetup.sh lunch full_panda-eng
instead of:
wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la...
tar -jxvf android-toolchain-eabi-linaro-*
export NUM_PROC=`getconf _NPROCESSORS_ONLN`
make -j${NUM_PROC} HOST_CC=gcc-4.7 HOST_CPP=cpp-4.7 HOST_CXX=g++-4.7 TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_TOOLS_PREFIX=/path/to/toolchain/arm-linux-androideabi- boottarball systemtarball userdatatarball showcommands > build_log_YYMMDD.txt 2>&1 &
I think we do a few things here:
1. force a runtime compiler host version 2. force a target version that isn't in the built-in prebuilt tree 3. select to produce tarballs instead of .img files 4. select pandaboard 5. disable simulator
4. and 5. should already be selectable with lunch. 3. isn't, but at the same time I am not sure we want to change that hardcoded. for 2. and 1. I am not so sure about hard coding it either.
So I am not so sure about the concrete goal. I agree though that our tree should build and work if you just run lunch + make ... whether that's really exactly our build I don't know yet.
Maybe let's start and get it to build with just that.
On 12 June 2012 14:49, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 8:59 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 12 June 2012 12:48, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 7:39 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
The only thing I am not sure about is that I still haven't seen an official instruction that would build a full platform - including the kernel... so whatever we do, we might have slightly deviated way of doing things as we produce a fully bootable system
What do you mean. The kernel is built as part of the platform, like it is today.
IIRC, in gingerbread AOSP there was no manifest with a kernel inside. Hence whatever you did with lunch and munch you didn't end up with a bootable image.
Maybe they have a manifest with kernel for panda by now?
Actually all I want to use is the commands, we'd still build the kernel and everything else like we always do.
In general I agree though that sticking to the pristine upstream instructions is a worthwhile goal.
I think you misunderstood. All I want to do is to allow people to build Android using the instructions listed on android.com. These would be:
source build/envsetup.sh lunch full_panda-eng
instead of:
wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la...
tar -jxvf android-toolchain-eabi-linaro-*
export NUM_PROC=`getconf _NPROCESSORS_ONLN`
make -j${NUM_PROC} HOST_CC=gcc-4.7 HOST_CPP=cpp-4.7 HOST_CXX=g++-4.7 TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_TOOLS_PREFIX=/path/to/toolchain/arm-linux-androideabi- boottarball systemtarball userdatatarball showcommands > build_log_YYMMDD.txt 2>&1 &
I think we do a few things here:
1. force a runtime compiler host version 2. force a target version that isn't in the built-in prebuilt tree 3. select to produce tarballs instead of .img files 4. select pandaboard 5. disable simulator
- and 5. should already be selectable with lunch. 3. isn't, but at
the same time I am not sure we want to change that hardcoded. for 2. and 1. I am not so sure about hard coding it either.
We can always change what actually happens in the build. but we should support the common build commands.
So I am not so sure about the concrete goal. I agree though that our tree should build and work if you just run lunch + make ... whether that's really exactly our build I don't know yet.
Maybe let's start and get it to build with just that.
The concrete goal is to unify the way we build each of or platforms so that users just have to run:
source build/envsetup.sh lunch full_panda-eng
and they'll get the same build they get today.
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Tue, Jun 12, 2012 at 9:56 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 12 June 2012 14:49, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 8:59 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 12 June 2012 12:48, Alexander Sack asac@linaro.org wrote:
On Tue, Jun 12, 2012 at 7:39 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Team,
Here's the idea, we put the build configuration and anything else we need to build the build into the build. We fix the builds so that people can use the instructions listed on:
The only thing I am not sure about is that I still haven't seen an official instruction that would build a full platform - including the kernel... so whatever we do, we might have slightly deviated way of doing things as we produce a fully bootable system
What do you mean. The kernel is built as part of the platform, like it is today.
IIRC, in gingerbread AOSP there was no manifest with a kernel inside. Hence whatever you did with lunch and munch you didn't end up with a bootable image.
Maybe they have a manifest with kernel for panda by now?
Actually all I want to use is the commands, we'd still build the kernel and everything else like we always do.
In general I agree though that sticking to the pristine upstream instructions is a worthwhile goal.
I think you misunderstood. All I want to do is to allow people to build Android using the instructions listed on android.com. These would be:
source build/envsetup.sh lunch full_panda-eng
instead of:
wget --no-check-certificate http://android-build.linaro.org/download/linaro-android_toolchain-4.7-bzr/la...
tar -jxvf android-toolchain-eabi-linaro-*
export NUM_PROC=`getconf _NPROCESSORS_ONLN`
make -j${NUM_PROC} HOST_CC=gcc-4.7 HOST_CPP=cpp-4.7 HOST_CXX=g++-4.7 TARGET_PRODUCT=pandaboard TARGET_SIMULATOR=false TARGET_TOOLS_PREFIX=/path/to/toolchain/arm-linux-androideabi- boottarball systemtarball userdatatarball showcommands > build_log_YYMMDD.txt 2>&1 &
I think we do a few things here:
1. force a runtime compiler host version 2. force a target version that isn't in the built-in prebuilt tree 3. select to produce tarballs instead of .img files 4. select pandaboard 5. disable simulator
- and 5. should already be selectable with lunch. 3. isn't, but at
the same time I am not sure we want to change that hardcoded. for 2. and 1. I am not so sure about hard coding it either.
We can always change what actually happens in the build. but we should support the common build commands.
So I am not so sure about the concrete goal. I agree though that our tree should build and work if you just run lunch + make ... whether that's really exactly our build I don't know yet.
Maybe let's start and get it to build with just that.
The concrete goal is to unify the way we build each of or platforms so that users just have to run:
source build/envsetup.sh lunch full_panda-eng
For that we should a) include our cross toolchain in the manifest b) include the TCWG native host compiler release in our manifest and update it monthly (also support validating TCWG release) c) hack the build system to use our target and host toolchain now pulled in by manifest c) hack the build system to produce tarballs by default
Open points: a) how to test daily toolchains? committing binaries to git is already kind of raw ... doing so daily is really rude :). b) how do we name our boards? I would start with a linaropandaboard style name that does not conflict with existing google platforms c) we said we will include tests in our default builds. Also we wanted to produce debug symbols and ship them in a separate tarball; can the lunch command express that? I assume something like "lunch full_linaropandaboard-tests-with-debug" or would we just go for -eng and put whatever we believe should be in a linaro build in there?
linaro-android@lists.linaro.org
-
Alexander Sack -
Zach Pfeffer