On Mon, Aug 28, 2017 at 06:10:26PM -0700, Gregory Szorc wrote: > On Mon, Aug 28, 2017 at 9:16 AM, Axel Hecht <l...@mozilla.com> wrote: > > > Hi, > > > > as some of you probably noticed, I've been hacking around our localized > > builds a bit over the past few weeks. > > > > Context: > > > > For https://bugzilla.mozilla.org/show_bug.cgi?id=1362617, I wonder where > > to put the generation of res/multilocale.json in a regular build. > > And I hope that someone volunteers to tackle l10n repacks for local > > artifact builds. > > > > Status: > > > > For desktop, we're now at the point where all that we do outside of > > browser/locales is jar packaging, and installer packaging. For android, we > > just need to move the search stuff from mobile/locales to > > mobile/android/locales. > > > > We're also only running the jar packaging once, and we're only running > > repack-l10n.py once. > > > > I also think we can drop the -j1 from the entry points. > > > > My hope here is that now that we're only using recursive make in a defined > > scope, and that parallelism isn't a problem anymore, we should have a > > better chance to get other backends to support repacks? Notably the > > artifact builds one? > > > > The flow of an l10n repack is also constructive now. It's preparing the > > localization, possibly getting a repo, and running compare-locales for > > l10n-merge. Then it's doing all the jar stuff, and then the app-specific > > funkyness like search. > > Then it packages the stuff as applicable for the project. One desktop, > > that's langpack, package, and possibly full mar. Then it creates a windows > > installer if on windows. On mobile, it's just the apk (and full mar?). > > > > All of this is done by explicit steps in the recipe, and I got rid of > > dependencies as much as possible. The dependencies turned out to be primary > > pain point, as they weren't dependencies to begin with. > > > > Questions: > > > > Where to put multilocale.json, in en-US builds, and in multi-locale > > builds, and in single-locale repacks? > > > > Do we need the XPI_ROOT_APPID='$(XPI_ROOT_APPID)' jazz? That makes the > > recipes way more complex than I think they should be. Some conditional > > hacks that we have depending on this could be replaced with > > IS_LANGUAGE_REPACK ? > > > > XPI_ROOT_APPID feels like something that should be defined once in the > entrypoint and shouldn't need to be passed around everywhere. But I have no > clue what all is keyed off of it. > > > > > > What do we really need to do to support l10n repacks on artifact builds? > > The build backend code is above me, sadly. > > > > Conceptually, an artifact build is a glorified cache. At the top of the > build we extract files from a previous build into their normal locations in > the objdir. And we disable all the build rules that would produce those > files. > > If l10n repacks were implemented as a post-build action that didn't > interfere with existing files (e.g. didn't delete binaries or other files > from the objdir it didn't itself produce), I would expect l10n repacks to > be compatible with artifact builds. The work to actually make them > compatible is likely a bunch of configure muckery and ensuring the artifact > build backend has enough context to let l10n repacks work. I wouldn't be > surprised if we were disabling things required by l10n repacks.
I, for one, think l10n repacks should be deprecated in favor of artifact builds. Because, really, when you take a step back, l10n repacks are just a special kind of artifact builds where the strings data is taken from a different place. Mike _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
