Closed Bug 1407374 Opened 3 years ago Closed 2 years ago

Port the INSTALL_TARGET in extensions/spellcheck/locales/Makefile.in to moz.build

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox59 fixed)

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: mshal, Assigned: ted)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

This is made slightly tricky since it pulls files from LOCALE_SRCDIR, so we need to find a way to support this in moz.build and still work with l10n.
Depends on: 1409721
I have a patch that uses the `LOCALIZED_FILES` implementation from bug 1409721 to do this. This is what `mach build-backend --diff` shows for the patch:
https://gist.github.com/luser/ffd3210ec7d614cd9dfaf855eba9a92d

The Makefile vs. backend.mk changes show that it looks to be generating functionally the same rules. The root[-deps].mk changes are because I removed the Makefile.in, so that directory no longer gets forced into the export tier, which is a nice side benefit. The install manifest changes are because the fastermake backend treats `LOCALIZED_FILES` the same as `FINAL_TARGET_FILES`, which should be fine for the time being. It has the other nice side effect that that means `mach build faster` will work for these localized files.
Attachment #8927991 - Flags: review?(core-build-config-reviews)
Comment on attachment 8927991 [details]
bug 1407374 - move hunspell dictionary copying to LOCALIZED_FILES in moz.build.

https://reviewboard.mozilla.org/r/199212/#review205006

If the prerequisites get hammered out, this will be fine.

::: extensions/spellcheck/locales/moz.build:7
(Diff revision 1)
>  # vim: set filetype=python:
>  # This Source Code Form is subject to the terms of the Mozilla Public
>  # License, v. 2.0. If a copy of the MPL was not distributed with this
>  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
>  
> +LOCALIZED_FILES.dictionaries += [

Is this that one weird consumer?  It would be nicer to bake the AB_CD into the .aff and .dic file names, but I'll take this.
Attachment #8927991 - Flags: review+
Attachment #8927991 - Flags: review?(core-build-config-reviews)
Comment on attachment 8927991 [details]
bug 1407374 - move hunspell dictionary copying to LOCALIZED_FILES in moz.build.

https://reviewboard.mozilla.org/r/199212/#review205006

> Is this that one weird consumer?  It would be nicer to bake the AB_CD into the .aff and .dic file names, but I'll take this.

Yeah, it's the only thing using wildcards for localized content. Additionally, not every locale has hunspell dictionaries, so we really do need a special case to make it work.
Assignee: nobody → ted
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9110808927225f45a7667f5048e6b2dfd2f2242
bug 1407374 - move hunspell dictionary copying to LOCALIZED_FILES in moz.build. r=nalexander
Per bug 1409721 comment 53, I think this was the actual source of the bustage. I'll do a try push with just the commits from the other bug (including artifact builds) and if that works I'll re-land just those until I fix this.
Flags: needinfo?(ted)
Depends on: 1419055
The fix for the bustage is in bug 1419055, it was a bug in the FasterMake backend. I verified that pushing rest of the patches from bug 1409721 to try doesn't break artifact builds, so I'll re-land those until I get review on that fix.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0cfaf6902748f13a602ec69c5cd6f56b7713a4e5
bug 1407374 - move hunspell dictionary copying to LOCALIZED_FILES in moz.build. r=nalexander
https://hg.mozilla.org/mozilla-central/rev/0cfaf6902748
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.