Closed Bug 458014 Opened 16 years ago Closed 16 years ago

restructure browser/locales/


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: Pike, Assigned: Pike)




(1 file, 1 obsolete file)

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, 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.


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.
Here's the patch that does what the initial comment explains.
Attachment #341319 - Flags: review?(ted.mielczarek)
Comment on attachment 341319 [details] [diff] [review]
refactor browser/locales/, support both manifests in

Merge conflicts, needs a new patch.
Attachment #341319 - Attachment is obsolete: true
Attachment #341319 - Flags: review?(ted.mielczarek)
Attached patch take twoSplinter Review
There are a few bustage fixes in this patch. The merge problem got backed out.

- 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.
Attachment #343208 - Flags: review?(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 :-(
Attachment #343208 - Flags: review?(ted.mielczarek) → review+
Yes, sadly, wget -N doesn't mix with --output-document, see for reference.

It'd probably be a good idea to get similar patches for the other l10n repackagings, too. Gozer, KaiRo?
Closed: 16 years ago
Resolution: --- → FIXED
-	  $(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?
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
Depends on: 460977
(In reply to comment #8)
> No, that's not intentional. File a follow-up bug on that?

Filed Bug 460977.
Blocks: 461513
Blocks: 464921
Depends on: 472431
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.