Open Bug 1387485 Opened 3 years ago Updated 4 months ago
L10n repacks don't work on artifact builds
AFAICT, this is mostly because l10n repacks do all kinds of things in all kinds of ways, and the buildfaster back-end doesn't want to follow that. I can understand that. Hoping to make things less crazy in bug 1385227. Still far away, though.
The first thing that's breaking l10n repacks is that for the faster backend, we don't put the JAR_MANIFEST := .../browser/locales/jar.mn into backend.mk. I struggle to understand how jar.mn processing works for faster builds, and how to best integrate this with repacks. On the symptom side, we could add JAR_MANIFEST to backend.mk inside an ifdef IS_LANGUAGE_REPACK, and regular artifact builds wouldn't see them outside of actual repacks. But I have no idea if that pill just kills the patient.
The faster make backend expects everything to be set at configure time. The "let's poke at a few make rules overriding some variables" scheme is not and won't be supported. L10n repacks need stop relying on make overrides.
We'll need a way to signal to the build system that we're doing a language pack, as long as the builds we do insist of creating platform-dependent l10n assets. As we're not going to create per-platform language packs.
It seems like it'd be straightforward to add something like `--enable-l10n-repack=ab-cd` and then use that in our repacks.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #4) > It seems like it'd be straightforward to add something like > `--enable-l10n-repack=ab-cd` and then use that in our repacks. I'm kind of wanting to avoid a need for a configure run to do a l10n repack, or at least multiple configure runs for each locale switch. I know thats not entirely the case today, but it may preclude being able to do `--enable-l10n-repack=ab-cd` But I don't yet have the build system improvements in my line of sight here, been focused on getting buildbot out of our way, so we can improve this for all platforms, and releases, all at once without caring as much about backwards compat with old system integrations.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #4) > It seems like it'd be straightforward to add something like > `--enable-l10n-repack=ab-cd` and then use that in our repacks. How would that work out for engineers wanting to do a localized version of their own build for testing purposes? Right now, they'd do ./mach package;./mach build installers-de and they'd have something testable where they expect it.
... worst bug to keep notes, but as we're keeping notes: We also need to support multi-locale builds on mobile, and also on desktop in the near future.
Just for my own notes, the issue with FasterMake is that it doesn't handle l10n repacks, but it doesn't actively get in the way of the RecursiveMake system. Yesterday I tried adding ac_add_options --enable-artifact-builds ac_add_options --build-backends="RecursiveMake","FasterMake" to my mozconfig, and my (Android!) things appeared to work. That combination of build-backends is exactly what non-artifact builds use -- see https://searchfox.org/mozilla-central/rev/8fa0b32c84f924c6809c690117dbd59591f79607/moz.configure#246 -- and that configuration should still support artifact builds. Of course, since it's not the default, it's not well tested.
You need to log in before you can comment on or make changes to this bug.