We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
Paul, I've got the syntax as:
https://android-build.linaro.org/builds/~pfalcon/git-build-config/
Still good?
Hello Zach,
On Mon, 2 Apr 2012 16:56:43 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
Paul, I've got the syntax as:
https://android-build.linaro.org/builds/~pfalcon/git-build-config/
Still good?
Yes, both the repository and config syntax are good. Let me know if there will be any issues/questions.
On 2 April 2012 23:56, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
Sounds good to me, execpt this probably is something where we should be using linaro_android_VERSIONNUMBER branches -- that way we can still get a (hopefully still) working config for building Gingerbread even after moving over to Jujuba if we ever need it...
ttyl bero
2012/4/3 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 2 April 2012 23:56, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
Sounds good to me, execpt this probably is something where we should be using linaro_android_VERSIONNUMBER branches -- that way we can still get a (hopefully still) working config for building Gingerbread even after moving over to Jujuba if we ever need it...
Hmm...you think so bero? I was thinking over how we update the manifests and It seems fairly linear to me. I was thinking we'd just name the configs after the builds and check them into master. For the released versions we'd cut release branches just like normal. 12.04-release, 12.05-release, etc.. Do you think this is rational or should we set out to develop on linaro_android_4.0.4, linaro_android_4.0.5, etc...
ttyl bero
2012/4/3 Zach Pfeffer zach.pfeffer@linaro.org:
Sounds good to me, execpt this probably is something where we should be using linaro_android_VERSIONNUMBER branches
Hmm...you think so bero? I was thinking over how we update the manifests and It seems fairly linear to me. I was thinking we'd just name the configs after the builds and check them into master.
It is fairly linear and not that big a deal -- but the configs do always include the version number (MANIFEST_BRANCH=). That's what makes me think it may be nice to have it in branches (or tag the last build of a certain version) just so we can build an older version if needed.
So far we haven't run into the situation of having to go back to an older build for some reason, and I hope we won't be -- but if we will be, it would be nice to just tell android-build to get the config for that version.
ttyl bero
2012/4/3 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
2012/4/3 Zach Pfeffer zach.pfeffer@linaro.org:
Sounds good to me, execpt this probably is something where we should be using linaro_android_VERSIONNUMBER branches
Hmm...you think so bero? I was thinking over how we update the manifests and It seems fairly linear to me. I was thinking we'd just name the configs after the builds and check them into master.
It is fairly linear and not that big a deal -- but the configs do always include the version number (MANIFEST_BRANCH=). That's what makes me think it may be nice to have it in branches (or tag the last build of a certain version) just so we can build an older version if needed.
So far we haven't run into the situation of having to go back to an older build for some reason, and I hope we won't be -- but if we will be, it would be nice to just tell android-build to get the config for that version.
Yeah, I think if we create config release branches we should be covered.
ttyl bero
2012/4/3 Zach Pfeffer zach.pfeffer@linaro.org:
Yeah, I think if we create config release branches we should be covered.
For the most part -- then we just need to keep track of when exactly we switched to what build (do you know off the top of your head what our last 2.3.3 based build was? I don't, but maybe it's because I just tend to move ahead and forget about old stuff, sometimes a bit too much ;) ).
ttyl bero
2012/4/3 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
2012/4/3 Zach Pfeffer zach.pfeffer@linaro.org:
Yeah, I think if we create config release branches we should be covered.
For the most part -- then we just need to keep track of when exactly we switched to what build (do you know off the top of your head what our last 2.3.3 based build was? I don't, but maybe it's because I just tend to move ahead and forget about old stuff, sometimes a bit too much ;) ).
Sure, okay fair enough example. Though I'm still thinking we should just go with master and create release branches from it. The history will be readable that way. We'll could mark each Android version switch with a branch.
ttyl bero
On 2 April 2012 23:56, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
And of course extra points for supporting a #include statement of sorts... Easiest way to do it should be just running the config through gcc -E -x c -P -C whatever.conf >current.conf
MANIFEST_FILENAME=staging-panda.xml #include "android-4.0.4.conf" #include "gcc-4.6.conf" #include "lava.conf"
ttyl bero
2012/4/3 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
On 2 April 2012 23:56, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
And of course extra points for supporting a #include statement of sorts... Easiest way to do it should be just running the config through gcc -E -x c -P -C whatever.conf >current.conf
MANIFEST_FILENAME=staging-panda.xml #include "android-4.0.4.conf" #include "gcc-4.6.conf" #include "lava.conf"
I think we'll have to do this as a separate step. Though repo does have this capability last I checked.
ttyl bero
Hello Bernhard,
On Tue, 3 Apr 2012 21:58:30 +0200 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
On 2 April 2012 23:56, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've been able to put configs in git for awhile. I'm going to go ahead and do this since we're at the start of the cycle. I'm just going to push to:
http://review.android.git.linaro.org/#admin,project,linaro/build-configs,bra... master
Sound good to everyone?
And of course extra points for supporting a #include statement of sorts... Easiest way to do it should be just running the config through gcc -E -x c -P -C whatever.conf >current.conf
MANIFEST_FILENAME=staging-panda.xml #include "android-4.0.4.conf" #include "gcc-4.6.conf" #include "lava.conf"
During work on the universal seed, I made a script to merge several manifests into one. That was merge as in set-theoretic union operation though, no warranties of order/human-readability. I intended to send a note to the list that it could be used as the basis for "manifest fragments" use (cf. with kernel config fragments which are now being adopted for kernel) - not sure if I sent such email.
Anyway, it's probably not important which combination approach we use, as long as it stays external to the repo. I.e., there should be 2 explicit notions: 1) includes/fragments supporting "ubermanifests", which are human-edited, 2) script to convert them into normal manifests, 3) automatically generated manifests directly usable by repo - all present all the time in repository (i.e., someone checks it out, edits manifest template, runs script, commits everything). The script can be as simple as Makefile.
ttyl bero
linaro-android@lists.linaro.org
-
Bernhard Rosenkränzer -
Paul Sokolovsky -
Zach Pfeffer