Am 29.08.17 um 03:10 schrieb Gregory Szorc:
On Mon, Aug 28, 2017 at 9:16 AM, Axel Hecht <l...@mozilla.com
<mailto: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
<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.
https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#1258
seems to be where they're used. Which ends up in
https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/jar.py#283,
and then I'm lost ;-)
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.
The first trigger for failing l10n repacks is that
make -C toolkit/locales chrome
doesn't actually do anything. At least that's as far as my research goes.
Which builds should run l10n-check in automation? I see that many
things disable that, and I'd like to have an entry point to run
l10n-related tests. We'll need that. Maybe it's time to have a
dedicated TC task for them?
As many of them as possible. Running l10n-check on any push where we do
a build seems like a reasonable target. I'm not sure if there are
perf/capacity concerns with that though.
Making a dedicated TC task for l10n-check seems reasonable. We try to
have more, smaller tasks than fewer, larger tasks. But, there are
compelling reasons to shoehorn into an existing task (namely scaling
concerns due to large setup/teardown costs or redundancy).
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1394733 to get it on
more generally.
Axel
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
