On 22 December 2011 07:13, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello Zach,
On Mon, 19 Dec 2011 11:37:27 -0600 Zach Pfeffer zach.pfeffer@linaro.org wrote:
Right now we have many build configurations. For example,
Do you mean "many", or "long", or "changing too often"?
No just, many, 9 official at last count.
https://android-build.linaro.org/builds/~linaro-android/staging-origen-11.12...
uses
MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro-android-11.12-release MANIFEST_FILENAME=staging-origen.xml TARGET_PRODUCT=origen TARGET_SIMULATOR=false TOOLCHAIN_URL=http://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.12... TOOLCHAIN_TRIPLET=arm-linux-androideabi REPO_SEED_URL=http://android-build.linaro.org/seed/pandaboard.mirror.tar.gz SOURCE_OVERLAY="origen/20111215/vendor.tar.bz2" LAVA_SUBMIT=1 LAVA_SUBMIT_FATAL=0 SYNC_JOBS=10
I'd like to move this into a git in 12.01.
Does this seem feasible?
Well, let's remember why we have build configuration process as it is now - to have it both flexible and extensible, and yet easy for any Linaro engineer (not only from Android team, but also from Validation, Kernel, etc.) to start using and use it. So, if we'll add "config from git" support, we'll still need to keep current "easy edit by hand" approach. Then, we'll have to approaches, with usual issues - more stuff to maintain, more stuff for folks to remember, harder to use/more chance of errors.
I'm fine dropping the current support for an only-in-git-approach. Bero, team, what do you guys think? To keep the flexibility we could expose 2 config variables, BUILD_CONFIG_GIT and BUILD_CONFIG_GIT_BRANCH (or just CONFIG and BRANCH).
In addition to this change I'd also like to be able to launch builds from the command line. Would that be possible?
It would also be cool to have a command line query about current builds.
So, what are specific factors to call for adding that "config from git"? If it's access control, I'd like to remind that we have special "linaro-android-official-builders" group, only its members can edit official builds. By limiting that group to 2-3 people for each release process, there can be better change tracking. And only of keeping explicit change log for (some) build configs is crucially required feature, than IMHO it's worth to complicate process with additional rules.
Its really about making it easier to configure and make builds en-mass. With a git approach I can do diffs of the configs etc...
...and to be super useful, the config mechanism would actually be extensible, meaning I could #include a central build file and the override things.
The other part, moving the kernel into the build config and out of the manifest would get us down to one manifest which would help.
Otherwise, technically, I don't see big problems with implementing that (at least in the simplest way), but that depends on more detailed spec for how it should look/work.
Here's a rough sketch:
On the build page you can set:
CONFIG=git://android.git.linaro.org/target/snowball_config.git BRANCH=release
On the command line you could have
android-build "CONFIG=git://android.git.linaro.org/target/snowball_config.git; BRANCH=release"
in the snowball_config you'd have:
#include git://android.git.linaro.org/target/global_config.git MANIFEST_FILENAME=landing-snowball.xml TARGET_PRODUCT=snowball
global_config.git would have: MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git MANIFEST_BRANCH=linaro_android_4.0.1 MANIFEST_FILENAME=default.xml TARGET_PRODUCT=snowball TARGET_SIMULATOR=false TOOLCHAIN_URL=http://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.12... TOOLCHAIN_TRIPLET=arm-linux-androideabi REPO_SEED_URL=http://android-build.linaro.org/seed/pandaboard.mirror.tar.gz SOURCE_OVERLAY="snowball/20111214/vendor.tar.bz2" LAVA_SUBMIT=1 LAVA_SUBMIT_FATAL=0 SYNC_JOBS=10
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog