Hello,
On Mon, 23 Jul 2012 12:36:35 -0700 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
On 23 July 2012 04:42, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Well, that's probably a known issue, that instructions on individual jobs' pages are out-of-date/incorrect. One reason being that we have them duplicated multiple times, so it's very hard/impossible to keep them all up to date over extended period of time. One solution proposed earlier was to not have adhoc per-job instructions, but instead make those pages link to one central wiki page, with single instructions applicable to all builds, maintained and up-to-date.
+1 -- just need to make sure that wiki page is actually kept up to date, and that it does list all weird issues with certain builds.
I was thinking that we could commit the toolchain tarballs to git and then just pull things as part of the manifest. That would help our local users.
There're 2 problems with that. 1st: who exactly will commit it to git? Again, toolchain build is automated daily process, and automated build script cannot commit to git (unless we're talking security issues).
We can probably make that reasonably save by limiting commits by the build script to one IP address?
Yes, sure we can limit/"fortify" access for such bot account if decided to go that way.
2nd: git (or any other source code version control system) is not designed to store large binary blobs and cannot handle them efficiently. So, toolchain tarball is currently 88Mb. In ten days, we'll have extra 880Mb in git repository.
That's a real problem. I'd propose not putting in the tarballs anyway (makes a git diff hard...). Instead, we could replace the prebuilts/* repositories in AOSP. That should make the load a lot less, given most of the time, not all subprojects change at the same time. It's still putting a lot of binaries into git though.
Obviously another alternative is to just build the toolchain as part of the normal build process, but that would make builds a lot more time intensive.
Yes, I wonder if putting toolchain in git will, while solving some problems, create other (delayed) ones. There're other alternatives besides those you mentioned - for example, instead of building toolchain as part of android build, there can be native android makefile to download that toolchain. Then, instead of committing entire toolchain, it will be enough to just commit changes to that Makefile to reference new toolchain...
ttyl bero