405856 - Figure out client.mk pulling of optional L10n directories

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Robert Kaiser]

We're adding extensions/irc to l10n/ using dependent langpacks (see <https://bugzilla.mozilla.org/show_bug.cgi?id=397246>), so that L10n of it can be optional, even if ChatZilla is built into SeaMonkey.
The only left problem currently is client.mk pulling the L10n files.
We have two options:
- either always pull the dir from l10n/, which means the dir itself needs to exist for every locale that has a SeaMonkey L10n or client.mk fails (just like we have it already with dictionaries),
- or always pulling all of l10n/ab-CD/ for all our products, which would solve this problem for all optional things we could have (we'd still leave the LOCALES_* variables in there for now, as the new compare-locales scripts need those to determine what to check).

Axel Hecht asked for Benjamin Smedberg to decide that, but he in turn forwarded this decision to build people, as he says the only reason he might not want to pull all of l10n/ab-CD is that it makes it more difficult to figure out what changes might affect Firefox - so on branches (for instance) we might have to be a lot more careful about managing l10n checkins.
He said on IRC "I think this should be brought up on mozilla.dev.builds and get rhelmer to concur on whatever decision... I don't care myself"

Rob Helmer seemed undecided on IRC when I explained this stuff to him on IRC, and on mozilla.dev.builds I didn't get any answer at all.

We'll need a bug for the eventual patch that comes up anyways, so here we are, but the question stands: What way should we go for this?

If locales ever move to hg, I'd expect us to pull all of l10n/ab-CD at once there anyways, but current L10n repackaging machines, esp. with Windows VMs having sucky I/O perf, would also probably take longer for a checkout.

I'm a bit divided between those solutions myself, both have their pros and cons, but I'd like to move forward on this soon, one way or the other.

From what I saw, all current (extensions/spellcheck) and planned-for-future (extensions/irc, extensions/venkman, maybe one time inspector) such parts are in extensions/ so we could even go and go for a middle-way approach to pull all of extensions/ or such, but not sure if that wouldn't be worse than one of the solutions above.

Comment 1

[Robert Kaiser]

Attachment: patch, v1: pull whole l10n/ab-CD/ dir with L10n checkout

This is the minimum patch to pull the whole l10n/ab-CD/ dir at checkout. I'm not changing anything else because apparently the l10n-checkout target relies on LOCALE_DIRS and the python compare-locales tool relies on the LOCALES_$(project) variables.

rhelmer said on the newsgroup:
"So for releases I think this would be fine, it would just take longer to do the l10n checkout than it currently does."

Comment 2

[Benjamin Smedberg]

Comment on attachment 291437 [details] [diff] [review]
patch, v1: pull whole l10n/ab-CD/ dir with L10n checkout

I'm fine with the code change, and I'm not about to make the policy decision.

Comment 3

[Robert Kaiser]

Comment on attachment 291437 [details] [diff] [review]
patch, v1: pull whole l10n/ab-CD/ dir with L10n checkout

Requesting approval. This change only makes us pull the whole locale directory for L10n builds, no actual code impact.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 291437 [details] [diff] [review]
patch, v1: pull whole l10n/ab-CD/ dir with L10n checkout

a=beltzner for 1.9

Comment 5

[Robert Kaiser]

Thanks, checked in.