If you don't want to read the whole post, all I propose is:
- create single-locale as usual
- continue with multi-locale build
For more details: we currently generate a single-locale build for Maemo devices (tar balls and deb files) which is composed of Fennec + XulRunner and as soon as we are done we trigger the localized builds for it. The process can be seen as:
- normal scheduler triggers the build
- check out code
- make -f client.mk
- repackage binaries, tests and deb files for Fennec and XulRunner
- upload tar balls and deb files
- trigger L10n parallelized jobs (the # of them is as many locales are defined in all-locales)
The changes I have made to the MaemoBuildFactory class to generate the multi-locale and the new MultyNightlyL10n can be seen like this (NOTE: The changes to the process are highlighted):
- The MultyNightlyL10n scheduler is triggered and passes as a property a list of locales based on the file maemo-locales (which currently contains 7 locales)
- check out code
- make -f client.mk build (we pass L10NBASEDIR variable)
- repackage binaries, tests and deb files for Fennec and XulRunner
- upload tar balls and deb files
- trigger L10n parallelized jobs (the # of them is as many locales are defined in all-locales)
- checkout compare-locales
- remove any tar balls or deb files
- for each locale defined:
- checkout the locale's code
- run compare-locale
- add the .jar files to the build (currently l10n-merged)
- repackage the Fennec tar ball and the deb file (NOTE: I pass the parameter AB_CD=multi instead of AB_CD=en-US)
- upload them
This means that beside the single-locale build we will upload the multi-locale build and we will still be able to generate the individual locale repackages based on the single en-US build.
Let me know if you have any questions or suggestions.
Armen
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.