On Wed, Oct 03, 2012 at 03:52:38PM +0200, Axel Hecht wrote: > On 03.10.12 15:41, Mike Hommey wrote: > >On Wed, Oct 03, 2012 at 02:54:19PM +0200, Axel Hecht wrote: > >>On 03.10.12 14:33, Mike Hommey wrote: > >>>On Wed, Oct 03, 2012 at 02:01:02PM +0200, Axel Hecht wrote: > >>>>I've looked a bit deeper into the code, and there's unused > >>>>functionality that I'd like to rip out of JarMaker.py in favor of > >>>>this: > >>>> > >>>>Support for multiple jars in one go is one thing I'd love to axe. > >>>>I've probably added that thinking we could one day just fire one > >>>>jarmaker for all of a language pack, but that doesn't need to be in > >>>>jarmaker itself, if we'd ever do that. > >>>> > >>>>I'm tempted to drop support for processing stdin, too. > >>>> > >>>>Much of that was there to be backwards compat, but these days we > >>>>only have two entry points into JarMaker, both passing in a single > >>>>file on disk (rules.mk and mobile's custom built search-jar). > >>>> > >>>>Ted? > >>>> > >>>>I'd hack on that, fwiw, and I'd do so quickly, as we'll want this in > >>>>18 for b2g :-/ > >>> > >>>Note that bug 780561 will make JarMaker always output "flat", at least > >>>when building firefox and firefox-l10n. > >> > >>That shouldn't be a problem for the gecko strings, they'll just be > >>where you'd expect them, with multiple locale codes and manifest > >>files. I'd actually expect things to become easier if the packager > >>picks up files directly from what's in the manifest files, as long > >>as we can point it to a list. Then we could avoid the hack over at > >>http://mxr.mozilla.org/mozilla-central/source/mobile/android/installer/Makefile.in#71 > >>? > > > >Actually, that hack can go away with the new packager, as long as all > >locales manifests are included in chrome.manifest. > > > >>How does that impact the langpack-% target, though? > > > >In practice, it changes nothing, because we already use flat chrome > >format for dist/bin. What changes with bug 780561 is that even for a > >final jar chrome format in dist/$APPNAME, we'll be using a flat chrome > >format in dist/bin. So JarMaker won't have to output jars directly. > > the langpack-% target doesn't do anything in dist/bin, it's doing stuff like > > @$(MAKE) -C ../../services/sync/locales AB_CD=$* XPI_NAME=locale-$* > BOTH_MANIFESTS=1 > > The logic starts in toolkit/locales/l10n.mk's langpack-% rule.
But that uses MOZ_CHROME_FILE_FORMAT, and aiui, the langpack-% rules are run with the same objdir as the repacks, which means MOZ_CHROME_FILE_FORMAT is probably flat already. Mike _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
