458014 - restructure browser/locales/Makefile.in

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Axel Hecht [:Pike]]

We're doing a few things oddly or inconvenient in repackaging locales, and I have a tree that tackles a first chunk of that.

- libs target

Right now, we're running a libs phase for each target we repackage, in particular because the langpacks need a different chrome manifest than the installers/packages.

I'm adding support for writing out both manifests at once to JarMaker.py, and refactor the Makefile to make all repack targets depend on the libs phase. That way, we only run through libs once for all two or three targets of repackaging.

- wget-en-US target

We're unconditionally getting the en-US binary right now, I'm changing the target to only download newer builds

- unpack target

This one is new, and actually depends on the downloaded package. No optimization for the windows installer yet. I'm factoring this one out so that I can ask application.ini for the SourceStamp, in the new ident target. This should help fix bug 398954, and the state of the tree is actually such that we could start hacking on that on the buildbot side.

I'm refactoring the removal of the localization dependent files from the package, too, so that we can re-use the staging environment from one repack to the next. Factoring this out should make it less error prone, too.

- LOCALE_MERGEDIR support

I'm adding a bunch of vpath magic and more arguments to MAKE_JARS_FLAGS to support a merge output dir in the build. That catches a flock of problems with incomplete localizations, though not all yet.

- merge target

Calling into compare-locales directly. Require compare-locales in a current version to be in the path, I don't think it's worth to add configure magic here.

- tests target

I'm moving the tests for installer variables into a cross platform test, and into the libs phase. That should leave us with less surprises for folks not working on windows natively.

Comment 1

[Axel Hecht [:Pike]]

Attachment: refactor browser/locales/Makefile.in, support both manifests in JarMaker.py

Here's the patch that does what the initial comment explains.

Comment 2

[Axel Hecht [:Pike]]

Comment on attachment 341319 [details] [diff] [review]
refactor browser/locales/Makefile.in, support both manifests in JarMaker.py

Merge conflicts, needs a new patch.

Comment 3

[Axel Hecht [:Pike]]

Attachment: take two

There are a few bustage fixes in this patch. The merge problem got backed out.

Changes:
- libs-% doesn't depend on merge-% anymore, I prefer to have those steps independent
- some windows bustage fixes to work around not being able to delete targets there

Tested on osx, ubuntu, xp, pushed to the try server successfully, too.
My local builds did show at least one successful l10n merge, too. Didn't go through the complete fuzz testing there yet.

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 343208 [details] [diff] [review]
take two

-	@$(WGET) -nv --output-document $(_ABS_DIST)/$(PACKAGE) $(EN_US_BINARY_URL)/$(PACKAGE)
+	(cd $(_ABS_DIST) && $(WGET) -nv -N  $(EN_US_BINARY_URL)/$(PACKAGE))

Does wget -N not work properly with --output-document? I don't see any other reason you'd make this change.

Reading this patch sort of makes my head hurt. I wish we had something better than make :-(

Comment 5

[Axel Hecht [:Pike]]

Yes, sadly, wget -N doesn't mix with --output-document, see http://www.gnu.org/software/wget/manual/html_node/Download-Options.html#Download-Options for reference.

Comment 6

[Axel Hecht [:Pike]]

FIXED, http://hg.mozilla.org/mozilla-central/rev/489b5d339c20.

It'd probably be a good idea to get similar patches for the other l10n repackagings, too. Gozer, KaiRo?

Comment 7

[Atsushi Sakai]

-	  $(ZIP) -r9D $(LANGPACK_FILE) install.rdf chrome chrome.manifest
+	  $(ZIP) -r9D $(LANGPACK_FILE) install.rdf chrome/$(AB_CD).jar chrome.manifest

This is not compatible with --enable-chrome-format=flat.
Is it intentional?

Comment 8

[Axel Hecht [:Pike]]

No, that's not intentional. File a follow-up bug on that? I'd be thankful for a tip what would make it, too. I guess I just need to do some ifdef and zip chrome/$(AB_CD) instead of chrome/($AB_CD).jar

Comment 9

[Atsushi Sakai]

(In reply to comment #8)
> No, that's not intentional. File a follow-up bug on that?

Filed Bug 460977.