487182 - JarMaker should not regenerate the jar if the source files are unchanged

Status: NEW

(Firefox Build System :: General, defect)

Description

[Arpad Borsos [:Swatinem]]

Attachment: broken patch

JarMaker should generate a make dependencies file and use it to not regenerate the jar files when the source files are unchanged.

The patch is basically copy&pasted from qsgen.py but does not work correctly. It does not rerun JarMaker if I 'touch' any of the source files. I hope a more experienced build dev can get it to work.

The patch saves ~5s (from 48 to 43s) of do-nothing build time with warm caches on my system.

Comment 1

[Gregory Szorc [:gps]]

I just stumbled upon this myself, so this is still a valid bug. The offending rule in question is around https://hg.mozilla.org/mozilla-central/file/abdbf0646a21/config/rules.mk#l1639. We have a double colon target always executing, boo :(

An annoying side-effect of the current behavior is Makefiles are "lazy" and leave no indication that this behavior occurs. For example, take https://hg.mozilla.org/mozilla-central/file/abdbf0646a21/browser/components/preferences/Makefile.in. A casual reader might infer that nothing is being done except marking other directories for traversal.

From my perspective, this is messing up my automated Visual Studio project generator (bug 687388) because I have no way of automatically determining that JarMaker.py should run. Therefore, I have to resort to brute force, which is unfortunate.

While a global manifest as a dependency would be a decent approach (the current patch), I would much prefer to have a variable inside the Makefiles that would instruct JarMaker to run. Even better, the source files would be enumerated in the Makefile and each could be installed as a dependency for the target. This would be consistent with how we do other things (C++, IDL, etc) today.

Comment 2

[Gregory Szorc [:gps]]

If this is done properly (individual file listings converted to target dependencies), it may also *increase* build times due to the additional stat()s required. However, I /think/ JarMaker will end up touching all the files anyway, so it might balance out.

Comment 3

[(not currently active) Ted Mielczarek]

It's a little weird at the moment, I'll grant that, since the presence of a jar.mn makes us do work. I don't know that I'm wild about having to list out dependencies directly, since then you're forced to duplicate information that's already in the jar.mn.