Closed Bug 966073 Opened 7 years ago Closed 7 years ago
Disable proguard in the in-tree mozconfigs until it can more reliably build
Because our expectations are low, we just retrigger like https://tbpl.mozilla.org/php/getParsedLog.php?id=33835106&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=33837463&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=33841267&tree=Mozilla-Inbound (that's the three times, so far, we've attempted to do a debug build on one push) all day long. That ain't right, and we should stick an export MOZ_DISABLE_PROGUARD=1 into http://mxr.mozilla.org/mozilla-central/source/mobile/android/config/mozconfigs/common until it can be made to actually, you know, *build*.
See Bug 946083.
Hardware: ARM → All
More examples of Proguard choking on inconsistent sets of classes because of junk leftover in the object directory from prior builds, it seems. A clobber should fix such madness but, of course, is costly. (But maybe what you need to get this particular build through). Also sufficient would be deleting the classfiles from the object directory between builds (At the cost of around 10s per build). Perhaps this is a sensible alternative to disabling Proguard outright. Disabling it for a nontrivial period may lead to patches landing that don't properly annotate their entry points, causing the world to end immediately after you turn it on again. As you might know, there's a bug for solving the problem with less of a kludge this that RNewman seems to have mostly figured out - Bug 946083.
Hardware: All → ARM
Yeah, the best short term solution is `make -C $objdir/mobile/android/base clean` prior to building.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 946083
You need to log in before you can comment on or make changes to this bug.