Open Bug 487182 Opened 12 years ago Updated 3 years ago

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

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Swatinem, Unassigned)

References

Details

(Whiteboard: [buildfaster:p3])

Attachments

(1 file)

Attached patch broken patchSplinter Review
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.
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.
Blocks: 687388
OS: Linux → All
Hardware: x86 → All
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.
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.
Whiteboard: [buildfaster:?]
Whiteboard: [buildfaster:?] → [buildfaster:p3]
Depends on: 924617
Blocks: 929147
No longer blocks: 929147
No longer blocks: 687388
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.