1893540 - Using the --faster flag during mach build doesn't capture front-end changes

Status: RESOLVED DUPLICATE of bug 1891665

(Thunderbird :: Build Config, defect)

Description

[Alessandro Castellani [:aleca]]

Since a few weeks ago running a mach build --faster after changing some simple front-end code doesn't produce any update to the built application as even simple CSS changes are not included.
Doing a full build is always needed.

This is reproducible on Windows, I haven't tested if this happens also in other OSs.

Comment 1

[Rob Lemley [:rjl]]

I've confirmed that mach build faster does not work on Windows build hosts. It does work when targeting Windows cross-compiled on Linux.

The problem also affects Firefox builds.

STR:

• Use Windows build machine with latest MozillaBuild, and having completed mach bootstrap.
• Clone mozilla-central (only)
• Create empty mozconfig file (--enable-bootstrap is default)
• Run mach configure and mach build
• Change a JS or CSS file under browser/base/ somewhere
• Run mach build faster

Expected:
The build system should at least update the changed file under $objdir/dist/bin/browser<...somewhere...>

Actual:
A few lines of output, but nothing substantial.

Comment 2

[Rob Lemley [:rjl]]

I did some digging, $objdir/faster/Makefile when building on Windows is quite short in length. The last lines are:

MOZ_BUILD_APP = browser
MOZ_WIDGET_TOOLKIT = windows
INSTALL_MANIFESTS =
include $(TOPSRCDIR)/config/faster/rules.mk

When cross-compiling, there's quite a bit more following the rules.mk line.

Additionally, INSTALL_MANIFESTS being empty like that looks quite wrong. The x-compile build has:

INSTALL_MANIFESTS = dist/bin dist/bin/gmp-clearkey/0.1 dist/bin/gmp-fake/1.0 dist/bin/gmp-fakeopenh264/1.0 dist/bin/localization

There' also a install-dist/bin target between INSTALL_MANIFESTS and the rules.mk line.

Looking at the code in mozbuild/backends/fastermake.py, it appears that several object attributes are empty. This file is a pain to debug, but I confirmed that self._install_manifests.keys() is dict_keys([]) and self._manifest_entries is defaultdict(<class 'set'>, {}). This would explain the empty INSTALL_MANIFESTS line in the Makefile.

That's as far as I got today. Maybe Alex can provide some insight.

Comment 3

[Alex Hochheiden [:ahochheiden] [he/him]]

:Glandium is probably more suited for this.

Comment 4

[Mike Hommey [:glandium]]

I can't reproduce. Neither the problem itself, nor the Makefile being truncated.

Comment 5

[Alessandro Castellani [:aleca]]

I can't reproduce anymore either, something must have fixed this.
Both Rob and I were able to reproduce this again by rolling back to the 25h so something in that range must have broken it and fixed it.
Leaving this open in case Rob wants to mark it as duplicate of another bug, otherwise I can close it as INVALID or WORKSFORME.

Comment 6

[Rob Lemley [:rjl]]

Hooray for hg bisect...

This was fixed by bug 1891665, which was originally caused by bug 1888370. Those bugs are working with config_status.py (mach configure) it makes sense.

$objdiir/faster/Makefile is created towards the end of mach configure as part of the FasterMake backend. Bug 1888370 parallelized backend configuration. Unless you're building on Windows ... which takes a non-parallel path, and the bug appears to be that only the first backend would have run. Full RecursiveMake was built, while FasterMake (and VS?) were not.