On 23 July 2012 14:36, 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?
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.
I think we should follow convention and replace Google's toolchain with ours - Google puts binaries in git and we'll need to to. Having anything outside of the manifest isn't going to scale.
That said we may want to check them into prebuilt-linaro/ and ship both our toolchain and Google's side by side. Then we can have just one build.
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.
ttyl bero