Supporting these files may depend on a solution for l10n.

Please CC me on all bugs related to changes to the l10n build system.

Ahh, sorry about that. Also I mixed this file up with toolkit/locales/Makefile.in. I'll file a separate bug for that.

The crashreporter-override.ini and updater.ini rules are handled in the patches on bug 1409721. We looked into this at our work week last week and the searchplugins stuff, while complicated, doesn't have to block tup because there's already a workaround for the fastermake backend that tup can use. We should still figure out how to move the Makefile.in rules for searchplugins to moz.build, but I think that's going to depend on fixing repacks first.

This ticket is racing against https://bugzilla.mozilla.org/show_bug.cgi?id=1437942 and friends; I'm commenting here in case we can make progress on the expression of things currently localized before changing the product (and build) requirements of searchplugins. Right now we have two distinct crufty implementations of locale-aware searchplugins generation, one in browser/locales/Makefile.in and one in mobile/locales/Makefile.in. For hysterical raisins they operate pretty differently; I'll mostly discuss the Desktop implementation here. We're doing a bunch of locale-aware work in b/l/Makefile.in to list search plugins for a locale and then package the correct ones in the omnijar. That gets incorporated into the jar.mn at https://searchfox.org/mozilla-central/rev/dc6d85680539cb7e5fe2843d38a30a0581bfefe1/browser/locales/jar.mn#63-69 With LOCALIZED_GENERATED_FILES we should be able to migrate the list.json part into moz.build. The searchplugins themselves are a little more tricky, but we should be able to figure out where to write the outputs. Like Bug 1464128, there's a question of whether we keep the entries in the jar.mn file (including a wildcard?) or just write into the correct locale-aware locations inside FINAL_TARGET.

Well, you wrote patches over there, so let's just call it a day here.